Tutorial Ubuntu 26.04 / Membatasi akses SSH dan layanan dengan UFW

Atur UFW setelah memastikan alamat sumber koneksi administrasi dan port layanan yang sebenarnya, lalu izinkan hanya akses yang diperlukan. Siapkan aturan untuk akses SSH yang sudah teruji serta konsol sebelum mengaktifkan firewall, kemudian verifikasi koneksi baru dari klien yang diizinkan dan yang tidak diizinkan.

Periksa listener dan aturan yang sudah ada

sudo ss -lntup
sudo ss -tn
sudo ufw status verbose
sudo ufw status numbered

UFW (Uncomplicated Firewall) adalah alat pengelola firewall host Linux. Jalankan pemeriksaan pada server dan catat alamat serta port tempat layanan menunggu koneksi. Hasil ss -lntup membantu memeriksa listener TCP dan soket UDP, sedangkan ss -tn memperlihatkan koneksi TCP beserta alamat peer. Cocokkan koneksi SSH yang sedang dipakai, bukan memilih sembarang baris.

NAT (Network Address Translation) atau VPN dapat mengubah alamat sumber yang dilihat server. Catat keadaan awal UFW, kebijakan masuk dan keluar, serta aturan yang ada sebelum mengedit. Jika UFW sudah aktif, pertahankan kebijakan tersebut dan tambahkan hanya perubahan yang diperlukan. Aturan allow yang lebih sempit tidak membatalkan aturan lama yang sudah mengizinkan sumber lebih luas; baca keseluruhan aturan sebelum menyimpulkan bahwa akses telah dibatasi.

Klien Linux yang diizinkan dalam latihan IP statis memakai alamat host-only 192.168.56.10, sedangkan server memakai 192.168.56.20. Jika administrasi dilakukan langsung dari host Windows pada topologi itu, sumber biasanya 192.168.56.1. Verifikasi melalui peer pada server dan alamat klien, lalu ganti .10 dalam seluruh aturan dengan sumber yang benar. Jangan memasukkan alamat adaptor NAT atau alamat tujuan server .20 sebagai sumber hanya karena alamat itu terlihat dalam konfigurasi.

Pastikan akses konsol VM atau penyedia benar-benar dapat dipakai sebelum mengubah firewall dari SSH. Jika perintah ufw belum tersedia, siapkan paket yang sesuai dan periksa kembali keadaan awalnya. Jangan menerapkan alur untuk VM kosong pada sistem yang dikelola alat firewall atau otomatisasi lain tanpa memahami kebijakannya.

Tentukan kebijakan awal hanya untuk VM latihan baru

Blok berikut mengasumsikan VM khusus tanpa aturan lama, klien administrasi 192.168.56.10, dan SSH pada TCP port 22. Ganti dengan nilai yang telah diverifikasi. Blok ini mengubah kebijakan bawaan lalu lintas masuk dan keluar; jangan menggunakannya untuk menimpa kebijakan sistem lain.

sudo ufw --dry-run allow from 192.168.56.10 to any port 22 proto tcp
sudo ufw allow from 192.168.56.10 to any port 22 proto tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing

--dry-run menampilkan perubahan yang direncanakan tanpa menerapkannya. Keberhasilan simulasi tidak membuat aturan aktif dan tidak membuktikan bahwa koneksi dari klien akan berhasil. Tinjau sumber, tujuan, port, serta protokolnya sebelum menjalankan baris penambahan aturan yang sebenarnya.

Tambahkan izin administrasi lebih dahulu dan pertahankan akses konsol. Aturan TCP port 22 tidak melindungi koneksi SSH pada port lain. to any berarti alamat tujuan pada host ini tidak dibatasi ke satu alamat tertentu; sumber tetap dibatasi ke alamat klien yang disebutkan. Kebijakan deny incoming bukan pernyataan bahwa semua paket dari semua protokol ditolak, karena UFW juga memiliki aturan dasar dan pelacakan koneksi.

Panduan firewall Ubuntu menjelaskan pembatasan sumber, status, serta simulasi aturan. Gunakan manual UFW untuk Ubuntu 26.04 saat memeriksa sintaks, kebijakan, dan dampak pengelolaan jarak jauh.

Izinkan layanan yang diperlukan dan aktifkan firewall

Jika layanan HTTP memang berjalan pada server latihan dan perlu diakses oleh klien tersebut, gunakan contoh berikut. Lewati baris pembukaan port 80 jika tidak ada layanan yang akan diuji; aturan firewall tidak memasang atau menjalankan server web.

sudo ufw allow from 192.168.56.10 to any port 80 proto tcp
sudo ufw enable
sudo ufw status verbose

Aturan port 80 hanya mengizinkan TCP dari sumber yang disebutkan untuk latihan HTTP. Baca peringatan saat enable. Pengaktifan UFW memuat ulang aturan dan dapat memutus koneksi yang sudah ada; mempertahankan terminal lama bukan jaminan bahwa sesi itu akan tetap hidup. Konsol adalah jalur pemulihan jika pengaturan sumber atau port keliru.

Periksa bahwa status menjadi aktif dan aturan serta kebijakan sesuai rencana. Dari terminal lain pada klien yang diizinkan, buat koneksi SSH baru ke akun, alamat, dan port yang sebenarnya. Jangan menutup jalur administrasi lama sebelum koneksi baru serta akses administrasi yang diperlukan berhasil.

Bedakan lapisan IPv6, cloud, dan kontainer

Periksa pengaturan IPv6 dalam /etc/default/ufw dan listener IPv6 pada hasil ss. Aturan dengan sumber IPv4 192.168.56.10 tidak sekaligus mengizinkan klien IPv6 tersebut. Sebaliknya, kegagalan akses melalui IPv4 tidak membuktikan bahwa jalur IPv6 juga tertutup. Inventarisasi alamat dan kebijakan yang benar-benar digunakan, lalu uji masing-masing jalur yang relevan.

Security group cloud, router, firewall host, dan firewall dalam VM merupakan lapisan terpisah. Layanan yang diizinkan oleh UFW masih dapat diblokir lapisan lain, sedangkan aturan UFW tidak menjelaskan seluruh jalur penerusan jaringan. Bedakan kesalahan rute, listener yang tidak tersedia, dan penolakan autentikasi dari pemfilteran paket.

Docker dapat membuat aturan sendiri ketika memublikasikan port kontainer. Dokumentasi resmi Docker mengenai firewall dan UFW menjelaskan bahwa lalu lintas port yang dipublikasikan dapat dialihkan sebelum melewati aturan UFW yang diharapkan. Karena itu, jangan memakai status UFW saja sebagai bukti batas keterpaparan kontainer.

Jika memakai kontainer, periksa alamat host tempat port kontainer diikat serta integrasi firewall untuk mode jaringan dan backend mesin yang sebenarnya. Uji port dari klien eksternal yang diizinkan untuk pengujian. Jangan menghapus aturan buatan mesin kontainer atau menonaktifkan pengelolaan firewall Docker secara sembarang, karena hal itu dapat merusak jaringan atau mengubah keterpaparan layanan.

Uji akses yang diizinkan, penolakan, dan pemulihan aturan

Dari klien .10 yang diizinkan, buat koneksi SSH baru ke server .20 dan, bila HTTP sudah tersedia, akses http://192.168.56.20/. Dari klien latihan lain yang tidak diizinkan, coba tujuan dan port yang sama. Pastikan klien kedua mempunyai rute ke server agar kegagalan rute tidak disalahartikan sebagai keberhasilan firewall.

Hasil yang diharapkan adalah koneksi layanan dari sumber yang diizinkan berhasil, sedangkan koneksi baru dari sumber yang tidak diizinkan tidak mencapai layanan tersebut. Dengan kebijakan drop, percobaan dapat berakhir karena timeout alih-alih pesan penolakan langsung. Bandingkan dengan listener dan keadaan layanan di server; layanan yang berhenti juga dapat menyebabkan koneksi gagal tanpa membuktikan pemblokiran UFW.

Untuk SSH, gunakan koneksi transport baru dengan pembagian koneksi dinonaktifkan, seperti dalam latihan SSH, bukan sesi lama atau multiplexing. Koneksi yang sudah terbuka dapat diperlakukan berbeda oleh pelacakan keadaan firewall. Catat hasil untuk IPv4 maupun IPv6 yang digunakan sebelum menyatakan pembatasan selesai.

Jika aturan HTTP berikut benar-benar ditambahkan hanya untuk latihan ini, hapus aturan itu setelah pengujian. Jika aturan yang sama sudah ada sebelumnya, pertahankan aturan lama dan gunakan catatan perubahan untuk menentukan apa yang perlu dibatalkan.

sudo ufw delete allow from 192.168.56.10 to any port 80 proto tcp
sudo ufw status numbered

Sesuaikan sumber dan port dengan aturan yang sebenarnya ditambahkan. Periksa hasil penghapusan serta daftar terbaru dan uji kembali akses yang harus tetap bekerja. Izin SSH yang masih diperlukan tetap dipertahankan. Jika menghapus berdasarkan nomor, ambil daftar baru setiap kali karena nomor berikutnya dapat berubah setelah satu penghapusan.

Menghapus aturan HTTP saja belum mengembalikan seluruh keadaan awal, karena latihan juga mengubah aturan SSH, kebijakan bawaan, serta status aktif. Untuk memulihkan VM yang semula tidak aktif secara penuh, bandingkan semua perubahan dengan catatan awal dan lakukan melalui konsol dengan rencana akses yang jelas. Jangan memakai reset atau menonaktifkan kebijakan yang tidak terkait untuk menghapus jejak perubahan. Jika akses hilang, perbaiki hanya sumber, port, atau aturan yang keliru melalui konsol dan uji koneksi baru lagi.