Konfigurasi Firewall: Menyusun Aturan Default-Deny Tanpa Mengunci Diri Sendiri

Memahami apa itu firewall cuma butuh waktu semenit: dia adalah penyaring yang menentukan trafik jaringan mana yang boleh masuk dan mana yang dibuang. Tapi benar-benar mengonfigurasinya dengan rapi adalah cerita lain — dan di titik inilah kebanyakan orang entah jadi bingung sendiri, atau diam-diam membuat server-nya lebih rapuh dari yang mereka kira. Jarak antara “aku tahu fungsi firewall” dan “aku punya aturan yang bersih dan benar sedang berjalan” persis inilah yang akan kita tutup di artikel ini.

Kabar baiknya, konfigurasi firewall yang kokoh untuk server biasa itu pendek. Kita bicara segelintir aturan, bukan tembok sintaks yang bikin pusing. Bagian sulitnya bukan jumlahnya — tapi mendapatkan urutan yang benar, memilih default yang tepat, dan tidak sengaja memutus akses kamu sendiri di tengah jalan. Begitu sekumpulan prinsip kecil di bawah ini kamu serap, kamu bisa mengonfigurasi firewall di hampir semua server dengan percaya diri.

Apa yang sebenarnya dikerjakan saat “mengonfigurasi firewall”

Mengonfigurasi firewall pada akhirnya cuma soal tiga keputusan, sisanya tinggal detail:

Kebijakan default — apa yang terjadi pada trafik yang tidak ditangani aturan mana pun secara eksplisit. Diizinkan, atau ditolak.
Aturan allow — trafik spesifik yang memang ingin kamu loloskan (port web-mu, akses pengelolaanmu).
Urutannya — karena firewall mengevaluasi aturan dari atas ke bawah dan berhenti di kecocokan pertama, susunan yang kamu tulis ikut menentukan hasilnya.

Itu saja seluruh pekerjaannya. Kalau kamu sudah membaca penjelasan yang lebih luas soal apa yang dilakukan penyaring ini dan kenapa, artikel firewall mengupas konsepnya dari ujung ke ujung. Di sini kita fokus ke praktiknya: mengubah konsep itu jadi konfigurasi yang benar dan berjalan, tanpa menembak kaki sendiri.

  KONFIGURASI FIREWALL ITU CUMA:

   kebijakan default  →  apa yang dilakukan saat tidak ada yang cocok
   aturan allow       →  segelintir hal yang kamu loloskan
   urutan aturan      →  kecocokan pertama menang, jadi urutan penting

Alatnya berganti, pola pikirnya tidak

Sistem yang berbeda hadir dengan antarmuka firewall yang berbeda — ada yang memberimu perintah sederhana untuk menambah satu aturan sekaligus, ada yang menyuruhmu menyunting tabel aturan langsung, dan platform cloud menyodorkan dasbor. Perintah persisnya memang bervariasi, dan itu wajar: artikel ini sengaja netral terhadap vendor. Yang berlaku di semuanya adalah modelnya — kebijakan default, aturan allow, urutan, dan pengujian. Kuasai modelnya sekali, dan tiap alat spesifik tinggal urusan mencari sintaks, bukan belajar ulang idenya.

Mulai dari default-deny

Ada dua filosofi yang bisa kamu pakai untuk membangun firewall, dan hanya satu yang pantas untuk mesin yang terbuka ke internet.

Default-allow: semua diizinkan kecuali yang secara khusus kamu blokir. Kamu harus menebak setiap hal berbahaya sejak awal dan menulis aturan untuk masing-masing. Lupa satu saja, terbuka lebar.
Default-deny: semua diblokir kecuali yang secara khusus kamu izinkan. Kamu hanya membuka pintu yang benar-benar perlu; sisanya tetap tertutup tanpa harus kamu sebut satu per satu.

Untuk server publik, default-deny adalah satu-satunya pilihan yang masuk akal. Kamu tidak berusaha mendaftar setiap kemungkinan ancaman — itu mustahil — kamu tinggal menutup semuanya, lalu menyisakan beberapa pengecualian yang memang dibutuhkan layananmu. Port database yang terlupa, sisa layanan uji coba, panel admin yang niatnya mau kamu hapus: dengan default-deny, tidak satu pun bisa dijangkau, karena kamu memang tidak pernah membukanya. Satu keputusan itu menghapus kategori risiko yang besar tanpa biaya.

Jadi hal pertama yang dilakukan konfigurasi yang baik adalah menyetel default trafik masuk jadi tolak:

  KEBIJAKAN (masuk):  DENY   ← blokir apa pun yang tidak diizinkan eksplisit
  KEBIJAKAN (keluar): ALLOW  ← biarkan server menghubungi luar (default umum)

Trafik keluar biasanya dibiarkan terbuka di awal — server-mu perlu mengambil update, berbicara dengan layanan lain, mengirim email. Memperketat aturan keluar adalah langkah lanjutan yang berharga untuk mesin sensitif, tapi trafik masuklah tempat perlindungan paling penting berada, jadi di situ dulu fokus kita.

Buka akses kamu sendiri sebelum memperketat apa pun

Inilah aturan yang menyelamatkanmu dari bencana firewall paling umum, jadi dia dapat bagiannya sendiri: sebelum kamu menyetel default jadi tolak, pastikan aturan yang meloloskan kamu sudah ada dan berfungsi.

Server tidak punya layar atau keyboard yang bisa kamu hampiri. Kamu mengaksesnya dari jauh, hampir selalu lewat SSH. Kalau kamu membalik kebijakan default jadi tolak padahal kamu belum mengizinkan port SSH-mu secara eksplisit, firewall akan memblokir koneksimu sendiri begitu dia aktif — dan kamu terkunci di luar mesinmu sendiri. Orang melakukan ini terus-menerus. Ini cara belajar yang benar-benar bikin keringat dingin.

Urutan yang benar selalu seperti ini:

  1. tambah aturan yang mengizinkan AKSESMU (SSH)   ← pertama, selalu
  2. tambah aturan untuk layanan publikmu (web)
  3. BARU setel kebijakan default jadi tolak
  4. uji dari koneksi kedua sebelum kamu percaya

Kalau SSH masih asing buatmu, artikel dasar SSH menjelaskan cara kerja login jarak jauh itu. Yang penting untuk urusan firewall cukup ini: SSH adalah tali penyelamatmu ke mesin, jadi aturannya datang lebih dulu, setiap kali tanpa kecuali.

Selalu sisakan pintu darurat

Bahkan dengan urutan yang benar, ada saja yang meleset — salah ketik nomor port, atau aturan yang tidak berlaku seperti dugaanmu. Dua kebiasaan melindungimu. Pertama, biarkan sesi SSH-mu yang sekarang tetap terbuka sambil kamu mengubah-ubah, lalu uji koneksi yang benar-benar baru di terminal kedua sebelum menutup yang pertama; kalau yang baru gagal, kamu masih punya sesi lama untuk membenahi. Kedua, di server cloud, kenali di mana letak web console penyedia (terminal berbasis browser yang melewati SSH) sebelum kamu membutuhkannya. Console itu jalan masukmu kembali kalau suatu saat kamu benar-benar terkunci di level jaringan.

Satu set aturan yang minimal dan benar

Untuk sebagian besar server di dunia nyata, seluruh firewall-nya cuma empat atau lima aturan. Beginilah rupa konfigurasi default-deny yang bersih untuk server web biasa, ditulis dengan bahasa sederhana supaya terbaca sama apa pun alat yang kamu pakai:

ALLOW   masuk  tcp  port 22    dari mana saja    (SSH — akses pengelolaanmu)
ALLOW   masuk  tcp  port 80    dari mana saja    (HTTP — biasanya dialihkan ke HTTPS)
ALLOW   masuk  tcp  port 443   dari mana saja    (HTTPS — website-mu yang sebenarnya)
ALLOW   masuk       related/established           (balasan koneksi yang kamu mulai)
DENY    masuk       selain itu semua              (default — tidak ada lagi yang masuk)

Beberapa hal patut digarisbawahi dari set ini:

Port 22 adalah SSH, jalan masukmu. Kalau kamu memindahkan SSH ke port non-standar (langkah hardening ringan yang umum), aturan ini memakai port itu. Apa pun pilihannya, dia tetap datang pertama.
Port 80 dan 443 adalah web publik. Kalau server-mu tidak melayani website, kamu tidak membukanya sama sekali — buka hanya yang benar-benar kamu jalankan.
Aturan established/related itulah yang membuat balasan bisa mengalir kembali. Sebentar lagi kita bahas kenapa ini perlu.
Baris tolak selain itu semua adalah kebijakan default yang sedang bekerja. Kamu tidak menulis aturan untuk port database atau port email — kamu cukup tidak pernah membukanya, dan default-deny menjaga mereka tetap gelap.

Untuk tahu port apa saja yang sedang mendengarkan (dan karenanya mungkin perlu kamu perhitungkan), kamu cek apa yang terikat ke jaringan:

# daftar layanan yang sedang mendengarkan di port jaringan
ss -tulpn

Jalankan itu di server yang masih segar, dan sering kali kamu akan menemukan layanan yang tidak kamu sadari sedang terbuka. Masing-masing entah sesuatu yang sengaja kamu buka, atau sesuatu yang seharusnya kamu hentikan dan hapus — yang langsung berkaitan dengan pola pikir hardening yang lebih luas: tutup pintu yang tidak kamu pakai, dan kunci yang kamu pakai.

Kenapa urutan aturan menentukan hasilnya

Firewall mengevaluasi aturan dari atas ke bawah dan bertindak pada yang pertama cocok. Setelah cocok, dia berhenti mencari. Ini terdengar seperti detail teknis sepele, tapi inilah sumber satu keluarga bug yang membingungkan, jadi layak kamu lihat dengan jelas.

Bayangkan kamu menaruh aturan luas “blokir semua yang masuk” di dekat atas, lalu aturan “izinkan port 443” di bawahnya. Karena aturan blokir cocok lebih dulu, trafik website-mu tidak pernah sampai ke aturan izin — dia diblokir, dan kamu garuk-garuk kepala bingung kenapa aturan yang jelas-jelas sudah kamu tulis tidak jalan. Aturannya jalan, kok; dia cuma dipotong duluan oleh sesuatu di atasnya.

   paket masuk ke :443
        │
        ▼
   aturan 1: BLOKIR semua masuk  ──► cocok ──► dibuang (berhenti)
   aturan 2: IZINKAN port 443    ──► tidak pernah tercapai
                                       ▲
                          ini bug-nya: urutannya salah

Perbaikannya adalah prinsip yang mengatur semua set aturan firewall: aturan allow yang spesifik berada di atas aturan deny yang luas. Daftarkan dulu hal-hal persis yang ingin kamu izinkan, lalu biarkan deny serba-cakup duduk di paling bawah (atau hidup sebagai kebijakan default, yang efeknya jadi kata terakhir). Buat urutan ini benar, dan sisa konfigurasinya cenderung langsung beres.

Aturan koneksi established, dan kenapa kamu memerlukannya

Ada satu kehalusan yang sering menjegal pemula. Saat pengunjung membuka website-mu, permintaannya datang masuk ke port 443 — aturan allow-mu menangani itu dengan baik. Tapi balasan dari server-mu pergi keluar ke port bernomor tinggi yang acak di mesin pengunjung. Kalau firewall menilai setiap paket secara terpisah, balasan itu akan terlihat seperti trafik keluar yang tak diminta, dan konfigurasi yang ketat bisa memblokirnya — mematahkan setiap koneksi.

Solusinya, firewall modern bersifat stateful: dia mengingat koneksi yang sudah pernah dia setujui. Saat kamu mengizinkan sebuah permintaan masuk, firewall membuat catatan dalam hati — “sekarang aku menanti balasan untuk percakapan ini” — dan otomatis meloloskan trafik balasan karena dia milik koneksi yang sudah terjalin. Kamu tidak menulis aturan terpisah untuk setiap kemungkinan port balasan; kamu menulis satu aturan yang berbunyi “izinkan trafik yang merupakan bagian dari koneksi established atau related”, dan itu mencakup semuanya.

  Pengunjung            Firewall                  Server
     │                      │                        │
     │  minta ke :443       │  cocok aturan ALLOW    │
     │ ───────────────────► │  (mengingatnya)        │
     │                      │ ─────────────────────► │
     │                      │                        │
     │   ◄─── balasan ──────│  ◄──── balasan ────────│
     │                      │  diloloskan otomatis:  │
     │                      │  aturan "established"  │

Inilah kenapa “izinkan koneksi established/related” hampir selalu jadi salah satu aturan pertama dalam konfigurasi mana pun yang waras. Dia aturan diam-diam yang membuat segala yang lain berjalan mulus. Lewati dia, dan kamu akan mendapati aturan allow-mu meloloskan permintaan masuk tapi entah kenapa tidak ada yang berfungsi — karena balasannya tidak bisa keluar lagi.

Jangan lupakan IPv6

Ini jebakan yang menjerat banyak orang: banyak sistem menjalankan dua firewall sekaligus — satu untuk IPv4 (alamat gaya 93.184.216.34 yang sudah akrab) dan satu untuk IPv6 (yang lebih panjang, gaya 2001:db8::1). Keduanya set aturan yang terpisah. Sangat mungkin kamu mengunci firewall IPv4-mu dengan rapi tapi membiarkan yang IPv6 terbuka lebar, sampai-sampai penyerang tinggal menyambung lewat IPv6 dan melenggang melewati semua kerja kerasmu.

Aturannya gampang: apa pun yang kamu lakukan untuk IPv4, lakukan juga untuk IPv6. Kalau salah satunya kamu setel tolak secara default, setel yang lain begitu juga. Kalau kamu membuka sebuah port di salah satunya, putuskan secara sadar apakah kamu mau dia terbuka di yang lain. Banyak alat firewall tingkat tinggi menerapkan aturanmu ke kedua keluarga alamat sekaligus, dan itu persis yang kamu mau — tapi kalau kamu bekerja lebih dekat ke lapisan mentah, kamu harus ingat ada dua set terpisah dan memeriksa keduanya. Sebuah server hanya sekuat belahannya yang lebih terbuka.

Cek kedua keluarga sebelum bilang selesai

Setelah mengonfigurasi firewall, ada baiknya kamu mendaftar aturan aktif untuk IPv4 dan IPv6, lalu memastikan keduanya sesuai niatmu. Konfigurasi yang terlihat rapat di IPv4 sementara IPv6 masih mengizinkan segalanya adalah celah dunia-nyata yang ternyata umum — dan karena konektivitas IPv6 sering aktif diam-diam, pintu yang terbuka itu tidak kelihatan sampai ada yang menemukannya. Dua menit memeriksa menyelamatkanmu dari lubang yang bisa membatalkan seluruh usahamu.

Host firewall vs security group cloud

Kalau server-mu berjalan di platform cloud, kemungkinan besar kamu punya dua lapis firewall yang tersedia, dan susunan yang kokoh memakai keduanya.

Host firewall berjalan di server itu sendiri, sebagai software yang kamu konfigurasi di mesin. Dia ikut ke mana pun server pergi dan bisa membuat keputusan yang detail. Ini firewall yang paling banyak disinggung pembahasan kita di atas.
Security group cloud (kadang disebut network ACL atau network firewall) berada di depan server-mu, menyaring trafik di pinggir milik penyedia sebelum dia bahkan sampai ke mesinmu. Kamu mengaturnya di dasbor, dan dia melindungi server bahkan kalau host firewall entah bagaimana salah setel.

Keduanya tidak bersaing — mereka saling memperkuat. Security group adalah gerbang perimetermu; host firewall adalah kunci di pintu gedung itu sendiri. Memakai keduanya adalah pertahanan berlapis: kalau satu lapis keliru, lapis lainnya tetap menahan. Satu konsekuensi praktis yang berguna kamu tahu: kalau trafikmu diblokir dan kamu tidak mengerti kenapa aturan host-mu kelihatan benar, periksa security group cloud — bisa jadi dia menolak trafik sebelum dia bahkan sampai ke mesin tempat aturanmu tinggal.

   internet
      │
      ▼
  ┌──────────────────────┐
  │  SECURITY GROUP CLOUD │   perimeter — menyaring di pinggir penyedia
  └──────────────────────┘
      │  (trafik yang lolos)
      ▼
  ┌──────────────────────┐
  │   HOST FIREWALL       │   di mesin — garis pertahanan terakhir
  └──────────────────────┘
      │
      ▼
   layanan-layananmu

Uji dulu, baru bikin menetap

Dua langkah terakhir memisahkan konfigurasi yang kelihatan benar dari yang benar-benar bisa kamu percaya.

Pertama, uji. Setelah aturanmu terpasang, pastikan tiga hal: port yang kamu buka bisa dijangkau dari luar, port yang tidak kamu buka tidak bisa, dan — yang paling penting — akses pengelolaanmu sendiri masih jalan dari koneksi yang segar. Uji paling sederhana adalah yang paling penting: buka sesi SSH baru sebelum kamu menutup yang sudah ada. Kalau dia tersambung, kamu aman. Kalau tidak, sesi lamamu masih di sana untuk membenahi masalahnya.

Kedua, bikin aturannya menetap. Ini langkah yang sering dilupakan pemula lalu bikin kena batunya: di banyak sistem, aturan firewall yang kamu tambahkan cuma hidup di memori dan hilang saat reboot. Kamu menyiapkan semuanya sempurna, server restart untuk update tiga minggu kemudian, dan tiba-tiba default-deny-mu lenyap dan semua port terbuka lagi — atau lebih buruk, layananmu jadi tak terjangkau. Apa pun alat yang kamu pakai, cari langkah “simpan” atau “aktifkan saat boot”-nya lalu jalankan, lalu reboot sekali dengan sengaja untuk memastikan aturannya kembali persis seperti yang kamu tinggalkan.

  1. terapkan aturan    →  konfigurasi aktif sekarang
  2. uji dari luar       →  port terbuka terjangkau, port tertutup terblokir
  3. uji aksesmu         →  sesi SSH baru tersambung
  4. simpan aturannya    →  bertahan melewati reboot
  5. reboot untuk cek    →  aturan kembali tanpa berubah

Kesalahan umum yang perlu dihindari

Supaya semua jebakan terkumpul di satu tempat, inilah kekeliruan konfigurasi yang paling sering bikin repot:

Menyetel default-deny sebelum mengizinkan SSH. Terkunci seketika. Izinkan aksesmu lebih dulu, selalu.
Urutan aturan salah. Deny yang luas di atas allow yang spesifik diam-diam memblokir trafik yang niatnya mau kamu loloskan. Allow yang spesifik di paling atas.
Lupa aturan koneksi established. Permintaan masuk tapi balasan tidak bisa keluar, jadi tidak ada yang jalan.
Mengunci IPv4 tapi membiarkan IPv6 terbuka. Firewall kedua yang menganga membatalkan yang pertama. Konfigurasi keduanya.
Tidak membuat aturannya menetap. Semua jalan sampai reboot berikutnya menghapusnya. Simpan dan verifikasi setelah restart.
Membuka port yang sebenarnya tidak kamu layani. Tiap port terbuka adalah sebuah pintu. Buka hanya yang kamu jalankan, jangan ada yang “untuk jaga-jaga”.

Tidak satu pun dari ini butuh keahlian mendalam untuk dihindari — ini daftar centang, bukan bakat. Jalani satu per satu setiap kali, dan konfigurasi firewall-mu akan benar sekaligus membosankan, yang justru persis kamu inginkan dari urusan keamanan.

Penutup

Ini gambaran utuhnya dalam satu tempat:

Mengonfigurasi firewall sebenarnya cuma tiga keputusan: kebijakan default, aturan allow, dan urutannya.
Selalu bangun di atas default-deny: blokir semua trafik masuk, lalu buka hanya segelintir port yang benar-benar dibutuhkan layananmu.
Izinkan akses SSH-mu sendiri lebih dulu, sebelum membalik default jadi tolak — dan sisakan pintu darurat (sesi yang terbuka, atau console cloud) supaya kamu tidak pernah bisa mengunci diri sendiri.
Set aturan minimal sering kali cuma SSH, HTTP, HTTPS, koneksi established, dan tolak sisanya.
Urutan penting — aturan allow yang spesifik di atas aturan deny yang luas, karena kecocokan pertama yang menang.
Aturan established/related itulah yang membuat balasan mengalir kembali lewat firewall stateful; tanpanya, permintaan masuk tapi tidak ada yang jalan.
Konfigurasi IPv6 agar selaras dengan IPv4 — firewall kedua yang terlupa adalah lubang yang senyap.
Pakai host firewall dan security group cloud sekaligus saat kamu punya keduanya: pertahanan berlapis.
Uji dari koneksi yang segar dan bikin menetap aturannya supaya bertahan melewati reboot.

Dengan firewall yang menutup pintu-pintu yang tidak kamu butuhkan, lapisan berikutnya yang layak diperkuat adalah pintu-pintu yang memang kamu biarkan terbuka — memastikan tiap layanan yang diloloskan itu sendiri sudah terkunci rapat, dan akses pengelolaan yang kamu andalkan dibuat sesulit mungkin untuk diserang.