Audit Port Terbuka dengan ss: 50 Socket di Satu VPS Ubuntu

Jawaban singkat: satu perintah ss -tulnH cukup untuk memetakan seluruh permukaan serangan sebuah host. Pada host uji Ubuntu 24.04.5, hasilnya 50 socket mendengarkan: 42 TCP dan 8 UDP. Dari jumlah itu, 18 baris mengikat alamat non-loopback, dengan port 22, 25, 53, 80, 443, 465, 587, 21115, dan 21116 terbuka ke semua antarmuka. Sisanya terikat ke 127.0.0.1 atau ke antarmuka Tailscale, artinya tidak terjangkau dari internet publik.

• TL;DR 50 socket mendengarkan terbagi jadi 42 TCP dan 8 UDP sebelum audit apa pun.
• 18 baris mengikat alamat non-loopback, sembilan di antaranya benar-benar terbuka ke semua antarmuka.
• Port 6379, 3000, 8080, dan 9000 pada host ini hanya terikat ke loopback, jadi tidak terekspos.
• Daftar port yang mendengarkan tidak sama dengan daftar port yang bisa dijangkau: firewall tetap penentu akhir.
• Simpan hasil audit sebagai berkas, jalankan ulang setelah setiap perubahan konfigurasi.

Audit permukaan serangan biasanya dilakukan dari luar dengan pemindai port. Padahal sisi dalam lebih murah dan lebih akurat untuk pertanyaan "apa yang sengaja dijalankan di mesin ini". Perintah ss membaca tabel socket kernel secara langsung, tanpa paket jaringan, tanpa waktu tunggu, dan tanpa risiko memicu sistem deteksi. Hasilnya juga memuat alamat pengikatan, yang justru informasi paling penting dan sering hilang dari hasil pindaian luar.

Perbandingan ss dan netstat untuk audit

Karena netstat sudah lama ditandai usang di kumpulan utilitas jaringan Linux dan tidak lagi mendapat pembaruan. ss berada dalam paket iproute2 yang sama dengan ip, membaca data langsung dari netlink, dan lebih cepat pada host dengan ribuan koneksi. Pada host uji ini ss mengembalikan 50 baris dalam hitungan milidetik, sesuatu yang tidak akan terasa berbeda untuk 50 socket, tapi sangat terasa pada server yang memegang puluhan ribu koneksi aktif.

Perbedaan yang lebih praktis adalah kelengkapan kolomnya. ss menampilkan alamat pengikatan persis, termasuk wildcard dan alamat IPv6, serta bisa memfilter berdasarkan state, port, atau proses pemilik socket dengan opsi yang konsisten. Untuk audit, dua hal itu sudah cukup: siapa yang mendengarkan, dan di alamat mana.

Cara membaca hasil ss

Pakai opsi -tulnH: -t untuk TCP, -u untuk UDP, -l untuk socket yang mendengarkan saja, -n supaya port tampil sebagai angka dan bukan nama layanan, serta -H untuk menghilangkan baris judul. Tanpa -n, port 53 akan tampil sebagai domain dan port 443 sebagai https, yang membuat penyaringan dengan awk atau grep jadi tidak konsisten antar-distribusi.

Kolom kelima adalah alamat pengikatan. Pola 127.0.0.1:5432 berarti hanya proses di mesin itu yang bisa menghubungi, sedangkan pola 0.0.0.0:5432 atau *:5432 berarti semua antarmuka, termasuk antarmuka publik. Pola [::]:5432 adalah versi IPv6 dan pada banyak sistem juga menerima koneksi IPv4 yang dipetakan, jadi jangan menganggapnya lebih sempit dari wildcard IPv4.

Langkah kedua adalah menambahkan nama proses dengan -p. Opsi ini butuh hak akses yang cukup untuk membaca socket milik pengguna lain, jadi jalankan sebagai root atau lewat sudo. Sesudah itu, hasilnya bisa disaring dengan satu pipeline sederhana untuk melihat hanya socket yang tidak terikat ke loopback, yaitu kandidat yang perlu dinilai.

Berapa port yang benar-benar terbuka ke publik?

Dari 50 socket yang mendengarkan pada host uji, 18 baris mengikat alamat non-loopback. Dua di antaranya adalah pasangan IPv4 dan IPv6 untuk port yang sama, dan tiga lainnya hanya terikat ke antarmuka Tailscale yang tidak dapat dijangkau dari internet. Sisanya adalah layanan yang memang dirancang untuk publik.

Kelompok	Port yang terlihat	Status yang wajar
Web publik	80, 443	normal, pastikan TLS dan header keamanan aktif
Remote shell	22	normal, wajib kunci SSH dan batasi sumber alamat
Email	25, 465, 587	normal bila host memang menjalankan MTA
DNS	53 TCP dan UDP	perlu diperiksa, resolver terbuka bisa dipakai amplifikasi
VPN mesh	21115, 21116, 41641	normal untuk RustDesk dan Tailscale
Hanya loopback	3000, 6379, 8080, 9000, dan lainnya	aman selama tidak ada proxy yang meneruskannya

Pengelompokan ini bukan penilaian otomatis benar atau salah. Port 25 yang terbuka wajar pada server email dan mencurigakan pada server web murni. Yang penting adalah setiap baris punya penjelasan. Bila ada port yang tidak bisa dijelaskan oleh siapa pun yang mengelola host, itu temuan yang harus diselesaikan lebih dulu sebelum urusan lain.

Apakah port yang mendengarkan berarti langsung berbahaya?

Tidak. Socket yang mendengarkan hanya berarti ada proses yang siap menerima koneksi. Apakah koneksi dari internet bisa sampai ke proses itu ditentukan oleh tiga lapisan: alamat pengikatan, tabel firewall di host, dan firewall jaringan di depan host. Audit ss hanya membaca lapisan pertama, dan itulah sebabnya hasilnya harus dipasangkan dengan pemeriksaan aturan firewall serta uji koneksi dari mesin lain.

Sebaliknya, bahaya justru sering muncul dari kombinasi yang terlihat rapi. Layanan yang terikat ke loopback bisa menjadi terekspos bila ada reverse proxy yang meneruskan seluruh path ke port itu tanpa autentikasi. Port yang tampak tertutup firewall bisa terbuka lewat aturan tambahan yang ditambahkan skrip lain. Karena itu, audit yang baik mencatat dua hal berdampingan: apa yang mendengarkan, dan apa yang meneruskan.

Untuk memastikan, uji dari luar dengan pemindai port sederhana ke alamat publik host. Bila hasil pindaian luar menunjukkan port yang tidak muncul sebagai wildcard di ss, berarti ada NAT atau proxy di antaranya, dan konfigurasi itu perlu ditelusuri. Bila sebaliknya, port wildcard tidak terjangkau dari luar, firewall bekerja seperti seharusnya.

Kapan audit ss sebaiknya dijalankan?

Setelah setiap instalasi layanan baru, setelah pembaruan besar yang mengubah unit systemd, dan minimal sekali sebulan sebagai pembanding. Cara paling berguna adalah menyimpan hasilnya ke berkas dengan nama bertanggal, lalu membandingkan daftar port dengan hasil sebelumnya. Selisih antar-berkas adalah daftar perubahan permukaan serangan, dan itu jauh lebih mudah dibaca daripada menatap 50 baris setiap kali.

Bandingkan juga dengan daftar unit yang aktif. Pada host uji ini terdapat 50 socket, dan jumlah itu masuk akal untuk mesin yang menjalankan web server, mail server, resolver DNS, VPN mesh, dan beberapa layanan internal. Pada mesin yang hanya menjalankan satu situs statis, 50 socket adalah sinyal untuk bertanya ada apa lagi yang berjalan.

Membuat audit port jadi rutin

Audit sekali jalan hanya memberi foto. Nilainya muncul ketika hasilnya disimpan dan dibandingkan. Pola yang paling sederhana: satu skrip kecil yang menjalankan ss dengan opsi -tulnH, mengurutkan hasilnya, lalu menuliskannya ke berkas dengan nama bertanggal di direktori log. Skrip itu bisa dijalankan manual setiap kali konfigurasi berubah, atau lewat penjadwal harian tanpa perlu LLM dan tanpa biaya token.

Pembandingan antar-berkas dilakukan dengan diff, dan yang perlu dibaca hanya baris yang bertambah. Baris yang hilang biasanya berarti layanan dimatikan, sementara baris yang muncul adalah permukaan serangan baru. Dengan cara ini, pertanyaan "apakah ada yang berubah sejak minggu lalu" hanya butuh satu perintah, bukan pembacaan ulang 50 baris dari awal.

Untuk port yang berubah, langkah berikutnya adalah menambahkan nama proses. Opsi -p memberi nama program, dan pada sistem dengan systemd, nama itu bisa dicocokkan dengan unit yang mengelolanya. Ini penting karena satu nama program bisa dijalankan beberapa unit berbeda dengan konfigurasi berbeda, dan menebak unit yang salah adalah penyebab umum perubahan konfigurasi yang tampak tidak berefek.

Yang tidak boleh dilakukan: memblokir port hanya karena tidak dikenal. Pada host uji ini ada port 2019, 3002, 4188, dan beberapa lainnya yang tampak asing tetapi bisa jadi bagian dari layanan sah. Sebelum menyentuh aturan firewall, pastikan pemiliknya, pastikan siapa yang memakainya, lalu putuskan. Audit yang menghasilkan pemadaman layanan karena satu port tidak dikenali adalah audit yang gagal, bukan audit yang berhasil.

Simpan juga catatan tentang alamat pengikatan, bukan hanya nomor port. Port yang sama di host berbeda bisa berarti hal yang sangat berbeda: 6379 di loopback adalah cache lokal, sedangkan 6379 di wildcard tanpa autentikasi adalah temuan serius. Karena itu, berkas audit yang baik memuat kolom alamat, bukan hanya daftar port.

Skrip audit juga tidak perlu hak istimewa bila hanya membaca daftar socket tanpa nama proses. Itu membuatnya aman dijalankan sebagai pengguna biasa lewat penjadwal pribadi, tanpa menambah aturan sudo. Bila suatu saat butuh nama proses, jalankan bagian itu terpisah sebagai root dan simpan hasilnya ke berkas yang bisa dibaca tanpa hak istimewa, supaya pembacaan rutin tetap murah.

FAQ

Apakah ss butuh akses root?

Tidak untuk melihat daftar socket dan alamatnya. Akses root atau sudo baru dibutuhkan saat menambahkan opsi -p untuk melihat proses pemilik socket milik pengguna lain. Untuk audit rutin, daftar port dan alamat pengikatan sudah cukup sebagai langkah pertama.

Kenapa port yang sama muncul dua kali?

Karena satu proses bisa mendengarkan di IPv4 dan IPv6 sekaligus. Pada host uji, port 22 dan 41641 masing-masing muncul di 0.0.0.0 dan [::]. Ini normal dan bukan duplikasi proses. Yang perlu diperiksa justru bila satu port hanya mendengarkan di IPv6, karena perilaku pemetaan IPv4 bergantung pada pengaturan kernel.

Apakah port 8080 di host ini terbuka ke internet?

Pada host uji, port 8080 terikat ke alamat antarmuka Tailscale, bukan ke semua antarmuka. Artinya hanya perangkat di jaringan Tailscale yang bisa menjangkaunya. Tetap periksa apakah ada reverse proxy publik yang meneruskan ke port tersebut, karena itu jalur lain yang tidak terlihat dari hasil ss.

Bagaimana kalau menemukan port yang tidak dikenal?

Jangan langsung memblokir. Cari dulu pemiliknya dengan ss -tulnp dan periksa unit systemd yang menjalankannya, karena memblokir port yang dipakai layanan sah bisa memutus akses yang dibutuhkan. Setelah pemiliknya jelas, putuskan apakah layanan itu memang perlu mendengarkan di alamat publik atau cukup di loopback.

Rujukan resmi untuk opsi dan perilaku yang dipakai di sini: halaman manual ss(8), halaman manual tcp(7), dan penjelasan dasar pemindaian port dari Nmap. Ketiganya cukup untuk memahami kenapa hasil dari dalam host dan dari luar jaringan bisa berbeda.