Memulihkan Akses dari Ruleset ufw yang Rusak

Dapatkan akses kembali terlebih dahulu

Jika ufw mengunci akses Anda ke VPS, gunakan console penyedia atau rescue mode untuk mendapatkan akses kembali. Tidak ada perbaikan berbasis SSH setelah aturan pemblokiran aktif. Kernel membuang paket Anda sebelum sshd menerimanya. Karena itu, Anda tidak dapat login atau melakukan perbaikan melalui jaringan. Buka console dari control panel penyedia, login pada prompt tersebut, lalu jalankan satu perintah.

sudo ufw disable

Anda akan melihat Firewall stopped and disabled on system startup. Koneksi SSH baru dapat digunakan kembali dalam satu atau dua detik. Tidak ada konfigurasi yang hilang. disable menghapus aturan dari kernel dan menulis ENABLED=no ke dalam /etc/ufw/ufw.conf, sedangkan aturan Anda tetap tersimpan di /etc/ufw/user.rules dan menunggu ufw enable berikutnya.

Jangan reboot dengan harapan masalah akan teratasi. ufw berjalan otomatis saat boot, sehingga ENABLED=yes berarti ruleset yang sama akan dimuat kembali sebelum jaringan aktif. Reboot tidak mengubah apa pun pada kondisi akses yang terkunci oleh ufw.

Konsol memerlukan kata sandi yang mungkin belum Anda miliki

Konsol web (VNC atau serial) adalah keyboard yang terhubung ke mesin. Konsol ini bukan jalur jaringan, sehingga tidak ada aturan firewall yang dapat memblokirnya. Konsol tetap memerlukan login lokal. Di sinilah konfigurasi yang hanya menggunakan key mengalami kegagalan: jika Anda tidak pernah menetapkan kata sandi untuk pengguna sudo dan login root terkunci, konsol menampilkan prompt yang tidak dapat Anda jawab. Tetapkan kata sandi tersebut sekarang, selagi Anda masih memiliki SSH: sudo passwd yourname. Sebagian besar panel juga dapat mengatur ulang kata sandi root, yang biasanya memaksa reboot.

Jika konsol tidak dapat digunakan, boot sistem rescue milik provider. Sistem ini menjalankan sistem operasi terpisah dengan disk Anda dalam keadaan tidak di-mount, sehingga Anda dapat menonaktifkan ufw dari luar.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Jalankan lsblk terlebih dahulu karena partisi root tidak selalu berada di /dev/vda1. Boot ulang ke sistem normal. ufw tetap nonaktif sampai Anda mengaktifkannya secara manual.

Urutan pemulihan minimal

Lakukan langkah-langkah ini secara berurutan. Empat langkah pertama aman. Langkah setelahnya tidak aman.

1. sudo ufw disable untuk membongkar aturan dan mendapatkan kembali akses Anda.
2. sudo ufw show added untuk menampilkan aturan yang Anda tambahkan, dalam bentuk perintah yang menambahkannya. Perintah ini berfungsi saat ufw tidak aktif, sedangkan ufw status tidak.
3. sudo sshd -T | grep -i '^port' untuk memastikan port tempat sshd benar-benar listening. Perintah ini menampilkan port 22 kecuali Anda mengubahnya.
4. sudo ufw allow 22/tcp, menggunakan port Anda yang sebenarnya, agar proses enable berikutnya tidak mengulangi penguncian akses.
5. sudo ufw enable, dengan menjadwalkan rollback terlebih dahulu. Penjelasannya ada di bagian bawah halaman ini.

Apa yang sebenarnya dilakukan ufw reset

ufw reset adalah langkah terakhir, bukan langkah pertama. Perintah ini menonaktifkan firewall, mencadangkan setiap file aturan, lalu mengembalikan aturan default menjadi menolak koneksi masuk dan mengizinkan koneksi keluar. Perintah ini menampilkan satu baris cadangan untuk setiap file:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

Setelah reset, tidak ada aturan allow sama sekali. Karena itu, jalankan perintah ini dari console, bukan melalui SSH, lalu tambahkan aturan SSH sebelum mengaktifkan firewall kembali. Cadangan tersebut berupa teks biasa. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 menampilkan aturan lama sehingga Anda dapat menyusun ulang ruleset yang sebenarnya tidak ingin Anda hapus.

Tempat ufw menyimpan aturannya

Membaca file lebih akurat daripada mengandalkan ingatan. Lima path menyimpan seluruh state:

• /etc/ufw/user.rules dan /etc/ufw/user6.rules: aturan yang Anda tambahkan, sesuai urutan evaluasinya.
• /etc/ufw/before.rules dan /etc/ufw/after.rules, serta varian 6: framework yang digunakan ufw untuk membungkus aturan Anda, termasuk aturan accept untuk koneksi yang sudah terbentuk dan aturan loopback.
• /etc/default/ufw: kebijakan default dan switch IPV6.
• /etc/ufw/ufw.conf: ENABLED dan level log.
• /var/log/ufw.log: daftar yang diblokir setelah logging diaktifkan.

ufw membuat salinan file dengan timestamp sebelum menulis ulang file tersebut. Karena itu, ls /etc/ufw/ akan berisi nama seperti user.rules.20260813_101500. Salinan tersebut merupakan riwayat untuk membatalkan perubahan. Sebaiknya baca riwayat ini sebelum mengembalikan perubahan.

Untuk melihat aturan yang dimuat di kernel, bukan aturan yang tersimpan di disk, gunakan sudo ufw show raw, atau sudo iptables -S dan sudo ip6tables -S. Pada Ubuntu 22.04 dan 24.04, perintah tersebut menggunakan backend nft. Karena itu, sudo nft list ruleset menampilkan aturan yang sama dalam sintaks yang lebih baru.

Mengapa mengaktifkan ufw memutus sesi SSH saya?

Kebijakan masuk default adalah deny. Mengaktifkan ufw tanpa aturan untuk port SSH akan memutus semua koneksi baru. ufw memang memberikan peringatan: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Menjawab y tanpa aturan allow untuk SSH adalah penyebab paling umum dari semua masalah di halaman ini.

Bagian yang membingungkan adalah jedanya. /etc/ufw/before.rules menerima paket dalam status ESTABLISHED,RELATED sebelum aturan Anda sendiri diproses, sehingga sesi tempat Anda menjalankan perintah tetap berfungsi normal. Pemutusan akses baru terlihat saat koneksi berikutnya, yang mungkin terjadi beberapa jam kemudian. Saat itu, perubahan firewall tidak lagi tampak berkaitan. Selalu buka sesi SSH kedua dan pastikan sesi tersebut berfungsi sebelum menutup sesi pertama.

Mengapa apt dan DNS berhenti berfungsi setelah perubahan kebijakan?

sudo ufw default deny outgoing memblokir kueri DNS (domain name system) keluar dan HTTP keluar. Akibatnya, resolusi nama berhenti dan pembaruan paket gagal. apt update melaporkan Temporary failure resolving 'archive.ubuntu.com'. SSH masuk tetap berfungsi karena responsnya berstatus ESTABLISHED dan lolos dari aturan framework. Hal ini membuat firewall tampak tidak terkait, padahal firewall adalah penyebabnya.

Jika Anda ingin menerapkan kebijakan yang menolak koneksi keluar, buka koneksi yang benar-benar dibutuhkan mesin:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Tanpa aturan terakhir, waktu sistem akan menyimpang. Waktu yang salah menyebabkan validasi sertifikat TLS (transport layer security) gagal. Akibatnya, curl mulai gagal karena tanggal, bukan karena port. Gejala ini muncul beberapa hari setelah perubahan. Karena itu, kebijakan penolakan koneksi keluar cocok untuk mesin yang Anda monitor, bukan untuk mesin yang hanya disiapkan sekali.

Mengapa aturan ufw saya tidak pernah cocok?

ufw mengevaluasi aturan pengguna berdasarkan urutan dan berhenti pada kecocokan pertama. deny yang ditambahkan setelah allow yang luas tidak pernah berlaku, karena aturan allow tersebut sudah menentukan tindakan terhadap paket. Tampilkan urutan aturan beserta nomornya, lalu sisipkan aturan pada posisi yang diperlukan.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp menampilkan aturan yang akan ditulis tanpa mengubah apa pun. Ini adalah cara yang aman untuk memeriksa aturan sebelum diberlakukan.

Ada satu jebakan lain pada profil aplikasi. sudo ufw allow OpenSSH menggunakan profil dalam /etc/ufw/applications.d/openssh-server, dan profil tersebut berarti port 22. Jika sshd mendengarkan pada 2222, aturan itu membuka port yang tidak digunakan oleh layanan apa pun dan membuat Anda terkunci di luar server, meskipun ruleset terlihat benar. Gunakan nomor port setelah Anda memindahkan port tersebut. Sintaks lainnya dibahas dalam dasar-dasar firewall ufw untuk VPS.

Mengapa aturan IPv4 tidak menjelaskan apa yang saya lihat?

Karena separuh trafik bukan IPv4. Ubuntu menyertakan IPV6=yes di /etc/default/ufw, lalu ufw mempertahankan ruleset v6 paralel di /etc/ufw/user6.rules. Aturan yang ditulis dengan alamat IPv4, seperti ufw allow from 203.0.113.10 to any port 22, sama sekali tidak membuat aturan v6. Jika VPS Anda memiliki data AAAA, klien Anda lebih memilih IPv6, dan koneksi Anda mengalami timeout, sementara ufw status menampilkan aturan yang tampak benar. Uji perbedaannya dengan ssh -4 user@host terhadap ssh -6 user@host. Jika yang pertama berhasil dan yang kedua tidak, masalahnya ada pada ruleset v6.

Kondisi sebaliknya lebih buruk dari sisi keamanan. Dengan IPV6=no, ufw sama sekali tidak mengelola ip6tables, sehingga kebijakan v6 tetap menggunakan nilai default kernel, yaitu ACCEPT. Port yang Anda kira tertutup merespons pada alamat IPv6-nya, dan tidak ada perintah ufw yang akan menampilkannya. Periksa dengan sudo ip6tables -S dan ss -tlnp, lalu baca cara ufw menangani port IPv6 untuk memahami keseluruhan situasinya.

Mengapa port Docker tetap terbuka saat ufw menolaknya?

Docker menerbitkan port dengan menulis aturan DNAT (destination network address translation) ke dalam tabel nat dan memasukkan chain-nya sendiri ke FORWARD. Aturan ufw berada di jalur INPUT. Trafik menuju container diteruskan, bukan dikirimkan ke host, sehingga tidak pernah mencapai chain yang berisi aturan penolakan Anda. docker run -p 5432:5432 dapat diakses dari Internet saat ufw aktif dan menolak semua trafik.

sudo iptables -t nat -S DOCKER

Solusi paling sederhana adalah menerbitkan port pada loopback: -p 127.0.0.1:5432:5432 mengikat sisi host ke 127.0.0.1, sehingga tidak ada koneksi eksternal yang dapat mencapainya, apa pun konfigurasi ufw. Menerbitkan port Docker melalui ufw membahas kasus ketika service memang perlu diakses publik.

Jadwalkan rollback sebelum menerapkan aturan

Kebiasaan ini membuat pengelolaan firewall tetap aman jika terjadi kesalahan. Sebelum menerapkan perubahan berisiko, jadwalkan pembatalannya. Jika perubahan tersebut membuat Anda tidak dapat mengakses server, mesin akan memulihkan konfigurasinya sendiri dalam lima menit sehingga Anda tidak perlu membuka console.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd menampilkan Running timer as unit: ufw-rollback.timer. Sekarang lakukan perubahan Anda. Jika Anda masih dapat membuka sesi SSH baru setelahnya, batalkan rollback:

sudo systemctl stop ufw-rollback.timer

Jika sesi tersebut tidak dapat dibuka, tunggu. ufw akan dinonaktifkan secara otomatis, lalu percobaan koneksi berikutnya akan berhasil. Trik shutdown -r +5 klasik tidak membantu pada ufw karena ufw memuat kembali ruleset yang sama saat boot.

Pertahankan cara akses kedua

• Masuk ke konsol provider sekali, sebelum Anda membutuhkannya, lalu pastikan kata sandinya berfungsi. Konsol yang belum pernah diuji bukan cadangan.
• Pertahankan pengguna sudo kedua dengan key miliknya sendiri agar satu file authorized_keys yang rusak tidak mengakhiri akses Anda.
• Periksa apakah provider menjalankan firewall jaringan di panel, terpisah dari ufw. Firewall tersebut memblokir port yang sama, dan ufw status tidak akan pernah menyebutkannya.
• Jangan menjadikan ufw allow from <your home address> satu-satunya aturan SSH jika alamat tersebut dinamis. Provider Anda dapat mengubahnya pada malam hari sehingga Anda kehilangan akses.

Waktu paling murah untuk melakukan semua ini adalah saat server masih baru, bersamaan dengan pekerjaan penyiapan lainnya di sepuluh menit pertama pada VPS baru.

Refused atau timed out menunjukkan lapisan yang mengalami kegagalan

Connection refused berarti paket mencapai server, lalu sesuatu mengirimkan TCP reset kembali. Jalur jaringan berfungsi normal, sehingga sshd berhenti atau mendengarkan pada port lain. Firewall jarang menjadi penyebabnya karena ufw secara default menjatuhkan paket, bukan menolaknya.

Connection timed out berarti tidak ada respons sama sekali. Ini merupakan ciri paket yang dijatuhkan oleh ufw, firewall jaringan penyedia, atau alamat yang salah. Memahami kedua error ini dengan benar menghemat waktu dan menghindari tebakan, sedangkan perbedaan antara connection refused dan timed out membahas kasus yang tersisa.

Aktifkan logging sebelum perubahan berikutnya

sudo ufw logging on
sudo tail -f /var/log/ufw.log

Paket yang diblokir akan terlihat seperti ini:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 dengan alamat Anda sendiri di SRC= membuktikan bahwa ufw yang memblokir koneksi, bukan jaringan dan bukan sshd. Pada image minimal tanpa rsyslog, /var/log/ufw.log tidak tersedia, dan baris yang sama berasal dari sudo journalctl -k | grep UFW. ufw membatasi laju aturan logging-nya sendiri, sehingga tidak adanya baris bukan bukti bahwa paket diizinkan.

Jika Anda menemukan aturan yang tidak pernah Anda tambahkan

Ruleset yang berubah sendiri bukan masalah firewall. Seseorang dengan akun root telah menulisnya. Jalankan sudo grep ufw /var/log/auth.log untuk melihat perintah sudo yang dijalankan dan akun yang menggunakannya, lalu jalankan last untuk memeriksa login di sekitar waktu tersebut. Jika akun-akun itu tidak cocok dengan siapa pun yang Anda kenal, hentikan pemeriksaan firewall dan ikuti checklist VPS yang telah dibobol sebagai gantinya. Mengaktifkan kembali firewall pada server yang dikendalikan orang lain hanya menyembunyikan masalah.

Satukan kembali

Setelah mengetahui penyebabnya, aktifkan kembali ufw dengan cara yang mencegah lockout terulang. Izinkan port SSH yang benar-benar Anda gunakan, jadwalkan rollback, aktifkan ufw, lalu buka sesi SSH baru dari terminal lain dan pastikan koneksi berhasil. Hanya setelah sesi baru tersebut aktif, tutup sesi yang sedang Anda gunakan. Biarkan logging aktif selama satu hari, karena log menunjukkan hal yang lupa Anda izinkan jauh lebih cepat daripada membaca user.rules.

FAQ

Apakah ufw disable menghapus aturan saya?

Tidak. disable menghapus ruleset dari kernel dan menulis ENABLED=no ke dalam /etc/ufw/ufw.conf. Aturan Anda tetap berada di /etc/ufw/user.rules dan /etc/ufw/user6.rules, sedangkan sudo ufw show added menampilkannya saat firewall tidak aktif. ufw reset adalah perintah untuk menghapus aturan tersebut, dan perintah ini mencadangkan setiap file terlebih dahulu dengan mencetak baris seperti Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

Apakah reboot VPS akan membatalkan pemblokiran ufw?

Tidak. ufw dijalankan saat boot dari ENABLED=yes di /etc/ufw/ufw.conf, sehingga aturan yang sama dimuat sebelum jaringan aktif dan Anda kembali terkunci. Reboot hanya membantu setelah Anda menonaktifkan ufw, atau setelah mengedit file tersebut dari rescue mode dengan disk ter-mount. Gunakan konsol dari provider, lalu jalankan sudo ufw disable di sana.

Mengapa container Docker saya tetap dapat diakses saat ufw menolak port tersebut?

Docker menulis aturan DNAT dan FORWARD sendiri untuk setiap port yang dipublikasikan. Trafik tersebut diteruskan ke container, bukan dikirimkan ke host, sehingga tidak pernah melewati chain INPUT tempat aturan penolakan ufw Anda berada. Gunakan -p 127.0.0.1:5432:5432 untuk memublikasikan port pada loopback jika port tersebut hanya digunakan oleh host, lalu periksa aturan yang dipasang Docker dengan sudo iptables -t nat -S DOCKER.

Saya tidak memiliki kata sandi konsol dan tidak memiliki rescue mode. Apa pilihan saya?

Pilihan yang tersisa bergantung pada provider Anda: reset kata sandi dari control panel, yang biasanya me-reboot server, atau memasang disk ke instance lain agar Anda dapat mengedit /etc/ufw/ufw.conf dari sana. Hubungi dukungan sebelum membangun ulang server, karena proses tersebut menghapus data di dalamnya. Setelah dapat masuk kembali, jalankan sudo passwd yourname dan uji login konsol sekali, sehingga pemblokiran berikutnya hanya memerlukan waktu dua menit.