Sophos Firewall: Tanpa CVE, Tetapi Penuh dengan Bug (v21.5 hingga v22)

Sophos Firewall: Tanpa CVE, Tetapi Penuh dengan Bug (v21.5 hingga v22)

20 min read
Network Sophos Security

Jika Anda saat ini bekerja di bidang firewall, Anda biasanya akan berhadapan dengan salah satu dari dua masalah besar: Anda terus-menerus stres karena kerentanan kritis (CVE, seperti Fortinet saat ini) dan menghabiskan malam-malam Anda untuk melakukan patching—atau sistem menempatkan begitu banyak hambatan di jalan Anda selama operasional reguler karena firmware yang tidak stabil dan bug yang mengganggu (seperti Sophos saat ini) sehingga Anda tidak dapat melakukan hal lain.

Dalam pekerjaan saya di perusahaan, hal terakhir inilah yang persis terjadi—sebuah stres yang tentu saja terkadang saya bawa pulang. Titik masalah kami saat ini bernama: Sophos Firewall.

Sementara pesaing seperti Fortinet tampaknya mengeluarkan pemberitahuan PSIRT baru setiap minggu, membuat administrator berputar dalam siklus patching yang konstan, Sophos secara besar-besaran menghabiskan waktu kami. Bukan karena kerentanan yang menjadi tajuk utama, melainkan karena bug yang benar-benar duniawi, namun kritis, dalam operasional sehari-hari.

Penyangkalan (Disclaimer), agar ini tidak terdengar seperti membandingkan apel dengan jeruk: Saya sepenuhnya sadar bahwa Fortinet juga berjuang dengan bug masif (pikirkan Conserve Mode dan Memory Leaks di FortiOS 7.2/7.4/7.6) dan bahwa Sophos juga tentu saja memiliki CVE parah di masa lalu. Namun, dalam fase v21.5/v22 saat ini, konstelasi spesifik inilah yang tepatnya menyakitkan bagi kami: Pada satu vendor, ini tentang patching CVE yang konstan; pada Sophos, ini adalah pekerjaan operasional yang tidak perlu yang disebabkan oleh masalah stabilitas.

Konteks Versi (TL;DR)

Hanya untuk memperjelas bahwa saya tidak sedang menulis tentang v19 lama yang berdebu, melainkan tentang apa yang saat ini dijalankan banyak orang sebagai versi “terbaru”:

  • SFOS 21.5 GA (02.06.2025): Catatan Rilis: SFOS 21.5
  • SFOS 21.5 MR2 (Build 323, 18.02.2026): Menurut catatan rilis, ini adalah versi 21.5 terbaru dalam jangka waktu ini.
  • SFOS 22.0 GA (Desember 2025) dan v22 GA Re-Release (Build 411, 20.01.2026): Catatan Rilis: SFOS 22.0

Ini adalah rilis GA (General Availability) dan Maintenance, bukan “nightly builds” acak.

Untuk memastikan bahwa perbandingan ini tidak hanya didasarkan pada perasaan, berikut adalah pemeriksaan realitas singkat.

Fortinet: CVE FortiOS sejak November 2025 (Per 26.02.2026)

Jangka waktu: 01.11.2025 hingga 26.02.2026 (Tanggal Publikasi). Sumber: Pemberitahuan PSIRT Fortinet (Ringkasan PSIRT).

Saya dengan sengaja tidak mencantumkan “semua Fortinet” di sini, tetapi hanya pemberitahuan yang relevan dengan FortiOS/FortiGate dalam periode ini, karena dalam praktiknya, di situlah letak masalahnya: Anda harus melakukan patch, merencanakan, menguji.

Skor CVSS bukanlah segalanya, tetapi hal ini membuat kontras operasional terlihat: Level Medium dengan skor 5.x sering kali dapat direncanakan, sedangkan skor 9.x dengan cepat menjadi skenario “hentikan segalanya dan segera lakukan patch”.

Dipublikasikan pada 10 Februari 2026 (Beberapa pemberitahuan di hari yang sama)

  • FG-IR-25-667 (CVE-2025-55018, CVSSv3 5.2): Request smuggling di GUI FortiOS. Tidak menyenangkan juga karena melibatkan “unlogged requests” (permintaan yang tidak dicatat).
  • FG-IR-25-795 (CVE-2025-64157, CVSSv3 6.7): Masalah Format-String dalam mode CAPWAP Fast-Failover (Admin/Config sebagai pemicu).
  • FG-IR-25-1052 (CVE-2026-22153, CVSSv3 7.5): Bypass Autentikasi LDAP di Agentless VPN/FSSO (Workaround dalam praktiknya sering kali: nonaktifkan unauthenticated bind pada server LDAP).
  • FG-IR-25-934 (CVE-2025-68686, CVSSv3 5.3): SSL VPN Symlink Persistence Patch Bypass. Penting untuk konteks: Menurut pemberitahuan, hal ini memerlukan kompromi sebelumnya melalui kerentanan lain pada tingkat sistem file.
  • FG-IR-25-384 (CVE-2025-62439, CVSSv3 3.8): Policy Bypass pada Agen FSSO Terminal Services (Perbaikannya adalah kombinasi dari versi FortiOS dan versi minimum dari Agen TS).

Januari 2026

  • FG-IR-26-060 (CVE-2026-24858, CVSSv3 9.4), dipublikasikan 27.01.2026: Bypass Autentikasi SSO FortiCloud Administratif. Pemberitahuan ini juga menjelaskan eksploitasi di alam liar (in the wild) dan tindakan pencegahan spesifik.
  • FG-IR-25-084 (CVE-2025-25249, CVSSv3 7.4), dipublikasikan 13.01.2026: Heap-based buffer overflow pada daemon cw_acd (FortiOS/FortiSwitchManager).

Dipublikasikan pada 9 Desember 2025

  • FG-IR-25-647 (CVE-2025-59718, CVE-2025-59719, CVSSv3 9.1): Bypass Autentikasi Login SSO FortiCloud melalui Pesan SAML yang dimanipulasi (Fitur ini tidak wajib secara default, tetapi nyata di lapangan).
  • FG-IR-25-411 (CVE-2025-62631, CVSSv3 5.3): Kedaluwarsa Sesi (Session Expiration) yang Tidak Memadai di SSL VPN (Masa pakai sesi/Kasus Ekstrem Perubahan Kata Sandi).
  • FG-IR-24-268 (CVE-2024-47570, CVSSv3 6.3): Informasi Sensitif berakhir di Log API REST (jika pencatatan log API REST aktif).
  • FG-IR-24-133 (CVE-2024-40593, CVSSv3 5.9): Kunci privat (private key) dapat dibaca oleh Admin (Kesalahan manajemen kunci, dapat diperbaiki melalui tingkat patch).

Dipublikasikan pada 18 November 2025

  • FG-IR-25-358 (CVE-2025-53843, CVSSv3 6.9): Stack buffer overflow pada daemon CAPWAP.
  • FG-IR-25-632 (CVE-2025-58413, CVSSv3 6.9): Masalah Stack buffer overflow lainnya pada daemon CAPWAP.
  • FG-IR-25-545 (CVE-2025-54821, CVSSv3 1.8): Bypass Trusted hosts melalui SSH (Kasus ekstrem CLI).

Ya, itu sangat banyak. Dan ya, Anda dapat mengelolanya dengan proses (Jendela Patch, Staging, Manajemen Perubahan, Jendela Pemeliharaan).

Dan kemudian datanglah sisi sebaliknya.

Sophos: Tanpa Berita Utama, Namun Operasional Sedang Terbakar

Dengan Sophos, tentu saja kita juga membicarakan tentang keamanan. Namun, apa yang benar-benar menghabiskan waktu kami saat ini hanyalah sekadar bug.

Saat ini kami memiliki begitu banyak pekerjaan yang tidak perlu di perusahaan hanya karena firewall terus menyebabkan masalah. Dan pada titik tertentu, Anda mendapati diri Anda mengajukan pertanyaan yang sebenarnya sangat absurd:

Apa yang lebih saya sukai: firewall dengan kerentanan keamanan yang berjalan secara stabil, atau firewall tanpa berita utama CVE besar yang tidak bisa menyala kembali setelah di-boot?

Ini bukan perdebatan akademis. Ini adalah Operasional (Operations). Sedihnya, saat ini saya hampir lebih memilih kerentanan keamanan teoretis yang mungkin suatu saat akan dieksploitasi daripada melihat jaringan pelanggan yang benar-benar mati selama beberapa jam lagi karena bug yang sepele.

Poin Masalah Kami Saat Ini (Ya, Semuanya Terjadi Sekaligus)

Dan untuk memperjelas: Ini hanyalah bug-bug yang telah kami alami berkali-kali dan pada sistem yang berbeda dalam beberapa bulan terakhir. Ini sungguh melelahkan dan membuat frustrasi ketika operasional berubah menjadi sebuah proyek. Terutama ketika Anda berakhir di komidi putar Dukungan (Support) Sophos lagi, dan mereka suka berpura-pura bahwa Anda adalah “satu-satunya pelanggan di seluruh dunia yang mengalami masalah ini”. Tidak, kami tidak sendirian.

  • Firewall terkadang tidak menyala dengan bersih setelah proses boot.
  • Kluster HA berantakan atau berperilaku seperti split-brain.
  • Pencatatan log (Logging) tiba-tiba menjadi tidak dapat diandalkan (atau hilang sama sekali).
  • Sertifikat Let’s Encrypt tidak diperbarui, dan Anda harus menindaklanjutinya secara manual di malam hari.
  • Sebuah antarmuka (interface) hilang atau tiba-tiba tidak terlihat lagi di GUI.
  • SSD mati (kerusakan perangkat keras).
  • Login WebAdmin mogok sepenuhnya – Anda tidak dapat masuk lagi, seringkali hanya reboot yang dapat membantu.
  • Antarmuka tiba-tiba hilang sama sekali dari konfigurasi.
  • Disk log penuh, menyebabkan pesan kesalahan muncul atau layanan yang terpengaruh berhenti secara langsung.

Apa Kata Komunitas (Anda Tidak Sendirian!)

Jika Anda melihat-lihat Komunitas Sophos (per awal 2026), gambaran penurunan kualitas sayangnya sejalan dengan pengalaman kami. Selain masalah kami, pengguna lain menghadapi hambatan (showstoppers) yang lebih parah di v21.5 / v22:

  • Profil VPN SSL Rusak (v22.0 Build 411): Beberapa pengguna melaporkan bahwa setelah memutakhirkan ke v22 terbaru, pembuatan profil VPN SSL gagal. Terkadang mereka harus melakukan rollback ke v21.5 karena versi baru tersebut terlalu banyak bug.
  • SNAT / Akses Server Web Rusak (v22.0 Build 365): Terdapat laporan bahwa setelah pembaruan, akses ke server web internal dari luar terputus. Seringkali, perutean internet mogok sepenuhnya sampai SNAT diatur ulang secara manual ke opsi MASQ default.
  • Spam CLI / “Invalid rule id”: Peringatan massal seperti “Invalid rule id or family for update” muncul di konsol. (Ini tampaknya “hanya” merupakan kesalahan tampilan, tetapi secara tidak masuk akal membanjiri log).

Dan bagian terpahit dari semua ini: Setiap hal ini bukan hanya mengganggu, ini adalah risiko yang masif. Jika log hilang, Anda terbang buta. Jika HA goyah, Anda kehilangan kepercayaan pada failover. Jika sertifikat tidak diperbarui, Anda membangun solusi sementara (workarounds). Dan solusi sementara adalah tempat berkembang biaknya insiden di kemudian hari.

Bug Sophos (v21.5 hingga v22): Langsung Menyerang Gejala Anda

Saya sengaja mencantumkan ID NC spesifik dari catatan rilis resmi atau Masalah yang Diketahui (Known Issues) yang didokumentasikan secara resmi di sini agar Anda, sebagai admin, dapat melacaknya dengan jelas.

TL;DR: Gejala -> Apa yang Tertulis di Catatan

Gejala dalam OperasionalContoh dari Catatan Rilis / Known Issues
Boot/Restart tidak menyala dengan bersihNC-151715, NC-152641, NC-123910
HA goyah atau eskalasi selama failoverNC-142962, NC-132291, NC-147307, NC-147739, NC-149039
Log/Laporan hilang atau tidak dapat diandalkanNC-158526, NC-160962, NC-157663, NC-169237, NC-135594, NC-175936, NC-170292, NC-166381
Let’s Encrypt/WAF menyebabkan stresNC-148937, NC-152022, NC-140663, NC-141062, NC-152540, NC-146082, NC-159041
Entra SSO/Captive Portal/VPN Portal bertingkahNC-167126, NC-157635, NC-167130, NC-167128
VPN/IPsec tidak menyala atau interop terputusNC-136352, NC-128116
Traffic Drops tanpa penyebab aturan yang jelasNC-169842 (dan ingatlah IPS/Snort sebagai penyebab setelah pemutakhiran)
Antarmuka “hilang” (UI)Masalah yang Diketahui: Nama antarmuka dengan 10+ digit membuat antarmuka tidak terlihat di tampilan WebAdmin

Kisah Frustrasi dari Operasional

Kami duduk di sana di pagi hari melakukan apa yang selalu Anda lakukan: Mengerjakan tiket, merencanakan perubahan, membaca pemantauan (monitoring).

Dan kemudian firewall mengetuk pintu, tanpa mengetuk.

Bukan dengan CVE, bukan dengan “Critical Advisory”. Tetapi dengan kehidupan sehari-hari.

Kopi pertama, restart pertama, dan pertanyaan di kepala Anda: Akankah ini menyala kembali atau tidak?

Jika keadaan berjalan baik, sistem akan menyala. Jika keadaan memburuk, sistem mendarat di suatu tempat di antara “Failsafe” dan “hidup, tetapi tidak memproses lalu lintas”. Dan saat Anda masih bertanya-tanya apakah Anda benar-benar membutuhkan kabel konsol lagi, bab berikutnya pun terbuka.

HA. Kantung udara (airbag) Anda. Dan terkadang rasanya seperti kantung udara mengembang saat sedang parkir.

Lalu pencatatan log. Kita semua tahu: Jika Anda tidak dapat melihat apa yang terjadi, Anda tidak dapat mengendalikannya. Dan tiba-tiba log menghilang, laporan kosong, atau sebuah layanan mengucapkan selamat tinggal. Anda berdiri di sana dan bertanya-tanya apakah Anda saat ini memiliki masalah keamanan, masalah kualitas data, atau keduanya.

Dan kemudian datanglah masalah utamanya: WAF, Reverse Proxy, Let’s Encrypt.

Anda bahkan tidak ingin menjadi mewah. Anda hanya ingin sertifikat diperbarui dan situs web Anda tidak berteriak “connection refused” pada pukul 02:13 pagi.

Dan sebagai bonus, sebuah antarmuka “menghilang”. Tidak benar-benar hilang, hanya hilang di UI. Lalu lintas mungkin saja masih berjalan, tetapi Anda tidak dapat melihat apa yang perlu Anda debug.

Pada titik tertentu, Anda menanyakan pertanyaan yang sebenarnya tidak masuk akal ini kepada diri Anda sendiri:

Apa yang lebih saya sukai: firewall dengan kerentanan keamanan yang berjalan secara stabil, atau firewall tanpa berita utama CVE besar yang secara operasional membakar lubang baru di lantai saya setiap minggu?

1) Boot, Reboot, Upgrade: “Dia hidup, tapi tidak bekerja”

Jika firewall tidak menyala dengan bersih setelah booting, itu bukan hanya masalah “waktu aktif (uptime)”. Itu adalah hari yang hilang ditambah risiko, karena dalam situasi seperti itu, Anda cenderung melakukan hal-hal yang tidak akan pernah Anda lakukan sebelumnya.

Beberapa contoh dari Catatan Rilis SFOS 21.5:

  • Failsafe saat restart: NC-151715 (Firmware Management): Perangkat Auxiliary beralih ke Failsafe saat restart; restart gagal.
  • Lalu lintas berhenti setelah peningkatan (upgrade): NC-152641 (Firmware Management): Setelah peningkatan (21.0 MR1 Build 237), tidak ada lagi lalu lintas yang diproses (Perubahan Konfigurasi Memori SWAP).
  • Kernel Panic: NC-123910 (Firewall): Masalah Kernel panic.

Dan ya: SFOS 22.0 memperkenalkan faktor pemutakhiran tambahan: Sophos menunjukkan dalam Release Notes bahwa v22 membawa perubahan arsitektur dan bahwa dalam kasus yang jarang terjadi, langkah manual tambahan mungkin diperlukan. Ini adalah tipe kasus ekstrem peningkatan yang menyakitkan dalam operasional.

2) HA: Kantung Udara yang Mengembang Saat Parkir

HA adalah jaring pengaman Anda. Dan itulah tepatnya mengapa sangat menyakitkan ketika kasus ekstrem meningkat tepat di sana.

Dari Catatan Rilis SFOS 21.5 (Pilihan):

  • HA Event Tracking berhenti saat restart bersamaan: NC-142962 (HA).
  • Unggahan Firmware di Pasif macet: NC-132291 (HA).
  • Failover menyebabkan Restart Loop: NC-147307 (HA) (secara eksplisit mis. XGS 2300 dalam catatan).
  • Sinkronisasi gagal setelah Pemadaman Listrik (Power Outage): NC-147739 (HA).
  • Status HA mengepak (flapped), Crash Dump pada Tautan Khusus: NC-149039 (HA).

3) Logging dan Reporting: Saat Anda Terbang Buta

Bagi saya, inilah alasan sebenarnya mengapa “bug” tidak hanya sekadar “operasional”. Ketika logging/reporting goyah, itu adalah masalah keamanan.

Dari Catatan Rilis SFOS 21.5 (Pilihan):

  • Logging/Reporting berhenti secara sporadis; coredump Garner sering terjadi: NC-158526 (Logging Framework).
  • Garner dan fwcm-heartbeatd berhenti: NC-160962 (Logging Framework).
  • Setelah Pemutakhiran: tidak ada lagi laporan: NC-157663 (Logging Framework).
  • Log Viewer kehilangan kejadian (events) karena Korupsi DB: NC-169237 (Logging Framework).
  • Korupsi deskriptor file (fd) Syslog, data dikirim ke FD yang salah: NC-135594 (Logging Framework).

Selain itu, Anda akan menemukan beberapa item dalam Daftar Masalah yang Diketahui (KIL) Sophos yang sama menyakitkannya dalam kehidupan sehari-hari:

  • Log Viewer tidak menampilkan data baru (active.db hilang): NC-175936 (Logging Framework). Pada beberapa sistem 21.5.1, active.db di bawah /tmp/eventlogs/ mungkin hilang. Kemudian Log Viewer “membeku”, meskipun lalu lintas dan fungsi keamanan terus berjalan. Menurut KIL, ini telah diperbaiki di v22 dan harus disertakan dalam perbaikan 21.5 MR2.
  • Positif Palsu (False Positive) “advanced threat detected” di HA: NC-170292 (Logging Framework). Sophos Central dapat mengirimkan peringatan dalam penyebaran HA, termasuk log mentah (raw logs) dalam deskripsinya. Solusi sementara (Workaround) menurut KIL: mulai ulang layanan Garner. KBA: https://support.sophos.com/support/s/article/KBA-000043672
  • ReportDB_v9 menampilkan STOPPED (terlihat dramatis, namun sebenarnya tidak): NC-166381 (Reporting). Setelah memutakhirkan ke v21.0 GA atau yang lebih baru, layanan ini akan muncul sebagai STOPPED setelah jangka waktu yang sangat spesifik. Menurut KIL, ini memang sudah diperkirakan dan tidak memiliki dampak operasional karena hanya memengaruhi pelaporan lama sebelum v21.

Dan inilah “Faktor Sophos Central”: Jika Anda menggunakan Central sebagai Single Pane of Glass, masalah logging akan menyakitkan dua kali lipat. Jika alur logging lokal (Garner/DB) terguling, unggahan ke Central Firewall Reporting (CFR) juga dapat gagal atau macet. Dan CFR tidak selalu berjalan “realtime” pula. Artinya: Dalam kasus terburuk, Anda tidak hanya kehilangan log lokal, tetapi juga kehilangan pandangan terpusat yang sebenarnya ingin Anda andalkan dalam kehidupan sehari-hari.

4) WAF dan Let’s Encrypt: Layanan Publik, Namun Tolong Tanpa Drama

Ketika sertifikat tidak diperbarui dan proxy terbalik (reverse proxy) berputar tak terkendali, itu bukanlah “bug kecil”. Itu adalah Dampak Pelanggan (Customer Impact) secara langsung.

Dalam Catatan Rilis SFOS 21.5, Anda akan menemukan seluruh keluarga masalah WAF/Let’s Encrypt:

  • Pembuatan sertifikat Let’s Encrypt gagal: NC-148937 (WAF).
  • Permintaan LE gagal karena Auto-Firewall-Rule hilang: NC-152022 (WAF).
  • Konfigurasi LE yang Tidak Valid menyebabkan Reverse Proxy terus-menerus restart: NC-140663 (WAF).
  • ACME tidak menerbitkan sertifikat untuk IP: NC-141062 (WAF).
  • Aturan WAF secara otomatis hidup/mati: NC-152540 (WAF).

Dan kemudian ada topik yang “terlihat seperti bug, tetapi merupakan pertukaran (tradeoff) keamanan”. Contoh dari KIL:

  • Garis miring yang disandikan (%2F) pada URL: WAF menampilkan 404: NC-159041 (WAF). Jika aplikasi Anda menggunakan garis miring yang disandikan (encoded slashes) di URL, Apache memblokir ini secara default (Arahan AllowEncodedSlashes di-default ke No) dan Anda melihat 404, meskipun backend “sebenarnya” memiliki jalur tersebut. Latar belakang: garis miring yang disandikan dapat menembus batasan jalur (contoh klasik: .../something%2F..%2Fadmin). Detail: https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes

Dan jika Anda ingin tahu seperti apa hal itu di lapangan: Di dalam utas komunitas ini, seseorang mendeskripsikan bahwa setelah memutakhirkan ke 21.5.x, sertifikat perpanjangan otomatis “hilang”, WAF tidak dimulai, dan situs web mati dengan pesan ERR_CONNECTION_REFUSED. Solusinya pada akhirnya adalah: Pembersihan Aturan Perlindungan Web (Web Protection Rules) dan menghapus CSR LE yang rusak, setelah itu sistem berjalan kembali. (Utas: WAF/Let’s Encrypt setelah Upgrade, ERR_CONNECTION_REFUSED).

Dan terkadang ini bahkan bukan sebuah “bug”, melainkan sebuah proses: Di Komunitas Sophos, ada juga kasus di mana Persyaratan Layanan (Terms of Service) Let’s Encrypt ditandai kedaluwarsa di WebAdmin dan harus disetujui kembali. (Utas: Let’s Encrypt Terms of Service have expired).

Klasik “perangkap pemutakhiran (upgrade trap)” tambahan dari Daftar Masalah yang Diketahui: Peningkatan (upgrade) dapat gagal jika sertifikat internal (onboard) sudah menggunakan nama yang sama dengan sertifikat Let’s Encrypt yang baru diperkenalkan di CA Store (NC-146082).

5) “Sebuah Antarmuka Hilang” (atau hanya tidak terlihat)

Ini adalah jenis bug yang terdengar kering dalam Catatan Rilis, tetapi memaksa Anda ke dalam penerbangan buta (blind flight) dalam praktiknya.

Secara resmi didokumentasikan sebagai Masalah yang Diketahui (Known Issue):

Jika antarmuka fisik atau logis dalam SFOS 21.5 GA dan yang lebih baru memiliki penunjukan yang berakhiran 10 angka atau lebih (Contoh dalam catatan: VLAN_1234567890), maka antarmuka fisik tidak terlihat di WebAdmin di bawah Jaringan (Network) > Antarmuka (Interfaces), atau antarmuka logis tidak dapat diperluas. Penting: Menurut Catatan Rilis, fungsinya tidak terpengaruh, hanya tampilannya di Konsol WebAdmin yang terdampak.

Kesimpulan sementara (sampai di sini): Boot/Upgrade, HA, Logging/Reporting, WAF/Let’s Encrypt, dan bahkan UI dapat menjegal Anda sekaligus. Mulai dari sini muncullah topik-topik yang pada awalnya terlihat seperti “detail jaringan” namun secara operasional sama mahalnya: Entra SSO, Interop VPN, dan lalu lintas yang tampaknya terputus secara acak (random traffic drops).

6) Identitas/SSO (Entra) dan Captive Portal: Saat Akses Terasa “Acak”

Ini adalah kategori bug yang sangat berbahaya dalam operasional: Bagi pengguna, hal ini terlihat seperti “akun saya sedang bertingkah”. Bagi Anda, hal ini terlihat seperti “itu hanya SSO”. Pada kenyataannya, sering kali firewall yang berada di tengah-tengahnya.

Beberapa masalah terbuka dari KIL jika Microsoft Entra ID (Azure AD) ada dalam bauran Anda:

  • Sophos Connect VPN: Akses Bersyarat (Conditional Access) tidak didukung sepenuhnya: NC-167126 (Authentication). Setelah tantangan MFA awal saat login pertama, pemeriksaan akses bersyarat tidak serta merta terpicu pada setiap koneksi berikutnya. Menurut KIL, penegakan kebijakan tidak terjadi lagi hingga pengguna keluar (logout) secara manual di Sophos Connect Client.
  • VPN SSO: UPN dan Email berbeda, Login terputus: NC-157635 (Authentication). Jika ID Email dan UPN di Entra berbeda, pengguna dapat mengakses Portal VPN, tetapi tidak ke Portal SSL VPN atau IPsec. Penyebab menurut KIL: header OAuth menyediakan Email, yang kemudian ditafsirkan sebagai UPN.
  • Captive Portal: Pengguna Entra SSO membutuhkan Grup Utama (Primary Group) di dalam Aturan: NC-167130 (Authentication). Akses internet hanya berfungsi jika Anda menggunakan Grup Utama di Kecocokan Aturan Firewall (Grup Sekunder tidak dihitung di sini). Perbaikan menurut KIL ada di “rilis pemeliharaan berikutnya”; Solusi sementara (Workaround): secara eksplisit cocokkan Grup Utama atau gunakan aturan berbasis pengguna.
  • Terkadang terjadi kesalahan “no permission” dengan Entra SSO: NC-167128 (Authentication). Dapat terjadi ketika Autentikasi ID Entra dan Autentikasi On-Prem AD digunakan secara paralel (Token-Reuse). Solusi sementara menurut KIL: hapus cookie browser atau “force re-logon” (paksa masuk ulang) di Sophos Connect Client. Alternatifnya, gunakan satu metode autentikasi secara konsisten.

7) Interoperabilitas VPN/IPsec: Pemutakhiran Sering Gagal Karena “Lawan”

Dua topik KIL yang tidak hanya dimulai dengan versi 21.5, tetapi tetap relevan di 21.5/v22 segera setelah Anda memiliki klien lama atau rekan jarak jauh di lapangan:

  • IPsec IKEv2: Terowongan (Tunnel) tidak menyala (Fragmentasi/PMTU): NC-136352 (IPsec). Dari 20.0 MR1, profil default IKEv2 dapat menghasilkan paket yang lebih besar (lebih banyak bidang default), terkadang lebih dari 1500 byte. Jika fragmentasi/PMTU di jalur perutean buruk (fragmen dibuang), terowongan S2S tidak akan menyala. Mitigasi menurut KIL: kurangi Grup DH (DH Groups) di profil IPsec (Minimal 4) atau konfigurasikan dengan tepat grup yang digunakan oleh rekan jarak jauh.
  • SSL VPN/OpenVPN 2.6.0: Ketidakcocokan dengan Klien EoL/UTM9: NC-128116 (SSLVPN). Sejak 20.0 MR1, OpenVPN menggunakan versi 2.6.0. Ini merusak SSL VPN dari situs ke situs (site-to-site) dengan versi SFOS lama (18.5 dan lebih lama), klien SSL VPN lama (EoL) dan OS UTM9, di antara yang lainnya. Rekomendasi menurut KIL: tingkatkan kedua belah pihak atau beralih ke IPsec/RED; Jarak jauh: gunakan Sophos Connect atau klien OpenVPN saat ini.

8) Lalu Lintas (Traffic) Terbuang Tanpa Kena Aturan: Accurate ECN sebagai Penyebab yang Menjengkelkan

Ketika lalu lintas tampak terputus secara “acak”, hal pertama yang Anda periksa adalah aturan (rules), IPS, inspeksi TLS, dan perutean (routing). Dan setelah pemutakhiran firmware, keadaan klasik akan ditambahkan ke dalam daftar: Mesin IPS (Snort) atau tanda tangan (signatures) menjadi lebih ketat, memblokir lalu lintas yang sah, dan Anda tidak segera menemukan peristiwa log yang jelas untuk itu. Kemudian Anda menghabiskan waktu berjam-jam untuk men-debug “routing” atau “rules”, meskipun pada akhirnya ini adalah pekerjaan tentang kebijakan (policy) atau penyetelan (tuning).

Akan tetapi, KIL juga memiliki kandidat yang dapat membuat Anda sibuk untuk waktu yang sangat lama jika Anda tidak memantaunya dalam radar Anda:

  • Lalu lintas terbuang (dropped) karena Bit Accurate ECN: NC-169842 (Firewall). Accurate ECN menyetel bit TCP (ECE/CWR/NS) secara berbeda (RFC 7560). Menurut KIL, kernel menafsirkan hal ini sebagai “reserved bit set” dan membuang lalu lintas. Untuk mempersempit masalah ini, memeriksa sisi klien akan sangat membantu: Dalam praktiknya, hal ini mungkin lebih disadari dengan kernel Linux yang lebih baru atau klien Apple, karena mereka cenderung menggunakan RFC 7560/Accurate ECN secara lebih aktif (“mengapa hanya MacBooks yang ditendang keluar?”). RFC: https://www.rfc-editor.org/rfc/rfc7560

9) v22 GA Re-Release Build 411: Mengapa pada awalnya hal ini diperlukan

Pada 20 Januari 2026, Sophos mendorong v22 GA sebagai rilis ulang (Build 411) untuk memperbaiki “masalah langka dan terisolasi”. Daftar tersebut terbaca seperti lagu hit dari “pekerjaan yang tidak perlu di jendela perubahan (change window)” (Sumber: Postingan Blog Komunitas Sophos di Re-Release):

  • NC-171003: WebAdmin tidak dapat dijangkau melalui Antarmuka Bridge dengan pemfilteran VLAN.
  • NC-170987: Log Spam CLI “Invalid rule id or family for update”.
  • NC-170970: Lalu lintas DNAT gagal jika Aturan DNAT memiliki antarmuka keluar (outbound interface) yang spesifik.
  • NC-171600: Widget SSL/TLS dan Data Bagan Sesi (Session Chart) salah/kosong.
  • NC-172197: Tidak ada konfigurasi SNMP yang dapat ditambahkan.

Postingan blog: v22 GA re-release (Build 411) is now available.

Kerusakan Nyata: Bug Membuat Keamanan Menjadi Lebih Mahal

Intinya bukanlah “bug lebih buruk dari CVE” atau sebaliknya.

Intinya adalah: Saat operasional Anda goyah, keamanan secara otomatis akan memburuk.

  • Anda menunda peningkatan karena Anda takut pada bug regresi berikutnya.
  • Anda menonaktifkan fitur (“kami tidak memerlukannya saat ini”) karena fitur tersebut menyebabkan stres.
  • Anda kehilangan kemampuan observasi (log), yang berarti kelambatan dalam merespons.
  • Anda menghabiskan waktu untuk memadamkan api (firefighting) alih-alih melakukan segmentasi, pencadangan (backups), dan membuat aturan yang bersih.

Dan satu hal yang sepenuhnya diremehkan dalam praktiknya: Time-to-Resolution (Waktu untuk Resolusi). Dengan CVE, Anda biasanya memiliki Advisory, Mitigation, dan Fix. Dengan bug, beban pembuktian (burden of proof) dengan cepat jatuh pada admin: tcpdump, log CTR, ekspor shell tingkat lanjut, “apakah Anda sudah mencoba mematikan dan menyalakannya lagi?” - sementara produksi (production) sedang terbakar. Dan setelah itu barulah Anda mendarat di komidi putar dukungan: peningkatan masalah (escalating), menunggu perbaikan terbaru (hotfix) atau MR berikutnya. Hal itu menghabiskan waktu operasional tambahan yang tidak Anda rencanakan.

Dan itulah persisnya mengapa pertanyaan “Lebih baik kerentanan, tetapi stabil?” adalah manusiawi, tetapi sebenarnya merupakan langkah yang salah:

Bukan hanya “kerentanan” yang menjadi masalah keamanan. “Firewall yang tidak stabil” juga merupakan masalah keamanan.

Apa yang Dapat Kita Pelajari Dari Hal Ini (Agar tidak benar-benar lepas kendali)

Beberapa hal yang membantu kami membatasi kegilaan ini tanpa perlu menemukan kembali roda setiap minggunya:

Preflight Peningkatan (Upgrade-Preflight) (Sebelum Anda Memulai)

  • Perlakukan Cadangan (Backups) seperti Pemulihan (Restores): Ekspor konfigurasi, cadangkan secara offline, dan pemulihan telah diuji setidaknya sekali.
  • Status HA “hijau” tidak cukup – uji failover-nya! Menurut GUI, sinkronisasi kami baik-baik saja dan heartbeat bersih. Tetapi dalam keadaan darurat, Alat Bantu (Auxiliary Appliance) tetap tidak mengambil alih failover dengan mulus. Tanda centang hijau di WebAdmin saat ini sayangnya bukan jaminan bahwa itu akan berfungsi selama jendela perubahan.
  • Verifikasi Logging: Syslog/Collector Eksternal menerima kejadian (events), tidak ada celah, waktu/NTP sudah benar.
  • Periksa Sertifikat/WAF: Tanggal kedaluwarsa, validasi Let’s Encrypt, dan sertifikat cadangan (fallback) sebagai Rencana B.
  • Benar-benar menguji SSO/VPN: Login Entra, Captive Portal, Sophos Connect, SSL VPN, IPsec S2S (termasuk failover) adalah kasus uji (test cases) mereka sendiri.
  • Persiapan Break-Glass: Konsol/Akses Out-of-band, admin lokal, citra (images) firmware untuk rollback.
  • Jangan lupakan Dual-Boot (dan jangan melebih-lebihkannya): Sophos memiliki dua partisi firmware. Jika sebuah pemutakhiran (upgrade) serba salah, rollback ke 21.5 seringkali hanya dengan me-reboot dengan memilih partisi yang lain. Namun: Ada juga kasus di mana partisi kedua juga tidak dapat boot dengan bersih, dan kemudian hanya reimage (instal ulang) yang dapat membantu (di mana tampaknya bagian dukungan memintanya dengan sangat cepat). Dan bahkan sebuah reimage tidak selalu memecahkan akar masalah yang sebenarnya.

Selama Peningkatan (Jika HA Terlibat)

  • Pasif/Sekunder terlebih dahulu, kemudian Failover, lalu Aktif.
  • Validasi singkat setelah setiap langkah: Lalu Lintas, VPN, DNS, Logging, WAF/Reverse Proxy.

Dalam Operasional Berkelanjutan

  • Uji HA, jangan hanya mengonfigurasinya: Latihan failover (Failover drills) dan kriteria yang jelas tentang kapan harus memisahkan sebuah kluster.
  • Perlakukan Logging sebagai sebuah Produk: Peringatan untuk celah log, Kesehatan Layanan (Service Health), ekspor darurat melalui CLI jika UI bertingkah.
  • Pantau Sertifikat secara Aktif: Perpanjangan bukanlah hal yang “bagus untuk dimiliki (nice to have)”, melainkan risiko operasional. Perlakukan perubahan ToS layaknya Perubahan Infrastruktur (Changes).
  • Health Check sebagai sebuah petunjuk, bukan KPI: Di v22, Sophos memperkenalkan Pemeriksaan Kesehatan (Health Check) (Detailnya ada di artikel saya Sophos Firewall v22 Health Check - Tinjauan Lengkap ). Ini bagus sebagai daftar periksa (checklist) praktik terbaik, tetapi terkadang terasa seperti “membalikkan sakelar ekosistem menjadi hijau”. Contoh dari praktik: Banyak orang mengaktifkan Penafian Login (Login Disclaimer) hanya untuk mendapatkan tanda centang hijau pada Pemeriksaan Kesehatan. Apa yang saya lewatkan di sana, adalah indikator operasional yang keras seperti “apakah DB logging/pelaporan sehat?” atau “bagaimana status SSD-nya?” - terutama karena beberapa peralatan mengalami masalah penyimpanan lebih cepat dari yang diharapkan.

Kesimpulan: Ketika Alat Menjadi Risiko

Pada akhirnya, kita semua berada di perahu yang sama. Kita mengelola infrastruktur kritis dan harus bisa mengandalkan alat yang seharusnya melindungi kita dari kekacauan, bukan malah menyebabkan kekacauan itu sendiri. Sophos jelas memiliki banyak pekerjaan rumah yang harus diselesaikan terkait kualitas firmware saat ini (v21.5 / v22). Kepercayaan pada “rilis yang stabil” telah mendapat pukulan telak bagi kami dan banyak orang lain di komunitas ini.

Saya tidak menginginkan firewall yang “entah itu aman atau stabil”. Saya menginginkan – tidak, saya membutuhkan – firewall yang memiliki keduanya.

Hingga Sophos dapat mengendalikan masalah kualitas ini, kita di bagian operasional hanya memiliki satu pilihan: Kita harus menjadi lebih disiplin, berhenti memedulikan “tanda centang hijau” di antarmuka pengguna (UI), dan menganggap serius bug yang biasa saja dalam perencanaan penyebaran (deployment) sama seperti CVE yang kritis.

Sampai jumpa lagi,
Joe

Sumber

© 2026 trueNetLab