Menanggapi Tailworm: memperkuat jaringan Tailscale kami tanpa mengganggu produksi

Cara kami memeriksa jaringan Tailscale terhadap temuan Tailworm, menghapus eksposur Tailscale SSH, dan menjaga semua job produksi tetap berjalan.

Ringkasan

Pada 25 Oktober 2026, seorang peneliti keamanan menerbitkan “Tailworm”: 11 temuan pada Tailscale dan headscale, yang dirilis tanpa pengungkapan terkoordinasi (coordinated disclosure). Pada saat artikel ini ditulis, Tailscale belum menerbitkan perbaikan. Malam itu juga, kami memeriksa jaringan Tailscale kami sendiri terhadap setiap temuan. Kami menghapus satu-satunya eksposur yang berlaku bagi kami, memperketat akses, dan semua job produksi tetap berjalan sepanjang proses.

Artikel ini menjelaskan apa yang kami periksa, apa yang kami ubah, bagaimana kami menghindari gangguan layanan, dan apa yang kami pelajari. Artikel ini bukan verifikasi independen atas laporan tersebut.

Ringkasan isi laporan Tailworm

Ke-11 temuan tersebut terbagi dalam beberapa kelompok:

• Tailscale SSH (paling serius). Sesi SSH yang sudah diotorisasi dapat dinaikkan menjadi root di mesin tujuan. Di lab peneliti, serangan ini kemudian menyebar dari satu mesin ke mesin lain.
• App connectors. Tujuan (destination) tidak divalidasi.
• Kehabisan memori, baik di server kontrol maupun di klien.
• Kasus tepi (edge case) pada Serve dan Funnel.

Setiap temuan mensyaratkan penyerang sudah memiliki pijakan di dalam sistem. Tidak satu pun merupakan serangan jarak jauh langsung dari internet. Sebagian praktisi keamanan berpendapat penyajiannya melebih-lebihkan risiko, tetapi eksposur utamanya, Tailscale SSH, memang nyata dan mudah dihapus.

Langkah 1: Periksa sebelum mengubah

Kami memulai dengan pemeriksaan yang hanya membaca data, dan mencatat hasilnya sebelum menyentuh apa pun:

• versi klien Tailscale yang digunakan
• fitur yang benar-benar aktif
• log sesi SSH selama 60 hari, untuk melihat siapa yang terhubung dari mana dan apakah ada yang menggunakan port forwarding atau socket forwarding
• daftar perangkat, termasuk perangkat yang sudah berbulan-bulan tidak terlihat

Temuan:

• Tailscale SSH aktif di sebagian lingkungan kami, sehingga temuan F1–F3 dan F5 relevan bagi kami.
• Fitur yang menjadi syarat temuan lainnya tidak digunakan, sehingga sebagian besar tidak berlaku.
• Log SSH tidak menunjukkan sumber yang tidak terduga maupun permintaan forwarding.

Langkah 2: Menghapus eksposur tanpa gangguan layanan

Solusi yang paling jelas adalah mematikan Tailscale SSH dan beralih ke autentikasi kunci OpenSSH standar. Namun pemeriksaan awal kami menemukan jebakan.

Tailscale SSH mengautentikasi berdasarkan identitas tailnet, bukan kunci SSH. Skrip otomasi kami memang menyertakan kunci SSH di baris perintah, tetapi kunci itu dilindungi passphrase dan tidak mungkin bisa bekerja tanpa pengawasan. Job-job tersebut hanya berjalan karena Tailscale SSH tidak pernah memeriksa kunci itu. Seandainya kami langsung mematikan Tailscale SSH, semua job otomatis akan berhenti.

Karena itu, kami melakukan peralihan dengan urutan berikut:

1. Membuat kunci khusus untuk otomasi, dibatasi hanya untuk satu mesin sumber, dengan forwarding dinonaktifkan.
2. Menguji jalur baru sebelum beralih. Kami membuka port OpenSSH sementara yang hanya dapat dijangkau dari dalam tailnet, lalu terhubung dari lingkungan yang sama dengan tempat job kami berjalan (tanpa SSH agent, tanpa terminal), dengan setiap cara skrip kami memanggil SSH.
3. Menjalankan uji negatif. Kunci baru ditolak dari luar sumber yang diizinkan, dan permintaan forwarding ditolak.
4. Menyiapkan rollback otomatis terlebih dahulu. Sebelum mematikan Tailscale SSH, kami menjadwalkan timer yang akan menyalakannya kembali secara otomatis. Jalur pemulihan ini tidak bergantung pada SSH yang berfungsi.
5. Beralih, lalu memeriksa setiap job otomatis dengan koneksi baru. Setiap job menyelesaikan satu kali eksekusi nyata. Kami tidak menganggap sesi yang sudah terbuka sebagai bukti.
6. Menghapus komponen sementara — port tambahan, aturan firewall, dan timer rollback — lalu memverifikasi sekali lagi.

Langkah 3: Memperketat sisanya

• Mengosongkan kebijakan Tailscale SSH. Kebijakan bawaan mengizinkan perangkat mana pun milik seorang pengguna membuka sesi SSH ke perangkat lain milik pengguna yang sama, termasuk sebagai root, cukup dengan persetujuan ulang di browser setiap minggu. Kami mengosongkannya, sehingga jika Tailscale SSH tidak sengaja dinyalakan kembali, akses tidak lagi diberikan.
• Menutup SSH dari internet. Sebelum menutupnya, kami memastikan login melalui konsol out-of-band berfungsi, agar kami tidak terkunci di luar. Setelah itu kami memverifikasi dari jaringan eksternal bahwa SSH tidak lagi merespons.
• Mewajibkan persetujuan perangkat. Perangkat baru harus disetujui administrator sebelum dapat bergabung.
• Memeriksa kunci pendaftaran. Tidak ada yang perlu dicabut.
• Memastikan MFA aktif pada akun administrator. Kontrol di tingkat jaringan dapat dibatalkan oleh siapa pun yang mengambil alih login admin.
• Mulai mengamati lalu lintas nyata antarperangkat, agar langkah berikutnya — mempersempit perangkat mana yang boleh berkomunikasi dengan layanan mana — didasarkan pada bukti, bukan tebakan.

Tailnet Lock dan persetujuan perangkat sama-sama melindungi dari perangkat liar yang bergabung, tetapi keduanya tidak dapat digunakan bersamaan, jadi pilihlah salah satu secara sadar.

Langkah 4: Perbaiki runbook, bukan hanya server

Prosedur pemulihan lama kami menyuruh menyambungkan kembali server dengan Tailscale SSH dalam keadaan aktif. Jika diikuti setelah perubahan ini, prosedur itu akan diam-diam mengembalikan fitur yang berisiko. Kami menulis ulang prosedurnya:

• Diagnosis terlebih dahulu. Apakah koneksi jaringan yang terputus, atau SSH itu sendiri (kunci, konfigurasi, firewall)? Keduanya memerlukan perbaikan yang berbeda.
• Sambungkan kembali tanpa mengubah pengaturan. Jangan gunakan flag tambahan, simpan pengaturan node sebelum menyambung kembali, lalu bandingkan sesudahnya.
• Buka akses darurat hanya dengan timer. Minta persetujuan terlebih dahulu, jadwalkan penutupan otomatis sebelum membuka, batasi sumber, serta periksa IPv4 dan IPv6.
• Jangan aktifkan kembali Tailscale SSH, bahkan dalam keadaan darurat. Perubahan kebijakan akses yang dibutuhkannya tidak dapat di-rollback secara otomatis.

Yang kami pelajari

1. Pahami apa yang sebenarnya diautentikasi oleh sebuah fitur keamanan sebelum menghapusnya. Kunci yang disebut dalam skrip kami tidak pernah digunakan.
2. Uji jalur yang akan Anda tuju secara persis, di lingkungan yang sama dengan tempat job Anda berjalan, sebelum beralih.
3. Siapkan rollback yang tidak bergantung pada hal yang sedang Anda ubah. Sebuah timer, bukan “nanti kita SSH masuk dan perbaiki”.
4. Periksa akses pemulihan sebelum menutup sebuah pintu. Kami memastikan akses konsol sebelum menutup SSH dari internet.
5. Perbarui runbook dalam perubahan yang sama. Langkah pemulihan lama dapat membatalkan perbaikan keamanan berbulan-bulan kemudian.
6. Baca kebijakan bawaan. “Izinkan perangkat milik sendiri, termasuk root” adalah pengaturan bawaan tempat kami memulai.
7. Pisahkan “perubahan berhasil” dari “kerentanan sudah teratasi”. Kami tidak lagi terekspos temuan Tailscale SSH, tetapi Tailworm secara keseluruhan belum tuntas sampai perbaikan dari upstream dirilis. Kami akan memperbarui klien kami saat perbaikan itu tersedia.
8. Ukur dulu, baru persempit. Data lalu lintas yang teramati dan daftar dependensi nyata harus ada sebelum aturan akses diperketat, agar penguatan keamanan tidak mengganggu bisnis.

Langkah berikutnya

Kami sedang mempersempit akses jaringan antarperangkat ke batas minimum yang dibutuhkan setiap layanan, berdasarkan lalu lintas yang teramati. Kami akan memasang perbaikan dari Tailscale segera setelah dirilis.

Referensi: laporan Tailworm (tailworm.com) dan dokumentasi Tailscale tentang Tailnet Lock.