Sophos Firewall: CVEはないが、バグだらけ(v21.5からv22)

Sophos Firewall: CVEはないが、バグだらけ(v21.5からv22)

4 min read
Network Sophos Security

目次

現在ファイアウォール分野で仕事をしていると、大抵の場合、2つの大きな悩みのどちらかと戦うことになります。一つは、致命的な脆弱性(CVE、最近のFortinetなど)による絶え間ないストレスと、夜通しのパッチ適用作業です。もう一つは、不安定なファームウェアと厄介なバグ(最近のSophosなど)により、日常の運用に支障をきたし、他の業務に手が回らなくなることです。

私の会社での仕事では、まさに後者が当てはまります。このストレスは、当然ながら家に持ち帰ってしまうこともあります。現在の私たちの悩みの種、それは「Sophos Firewall」です。

Fortinetのような競合他社が毎週のように新しいPSIRTアドバイザリを発表し、管理者を絶え間ないパッチ適用のサイクルに巻き込んでいる一方で、Sophosは私たちの時間を大量に消費しています。それは見出しを飾るような脆弱性のせいではなく、日常の運用において非常に平凡でありながら致命的なバグのせいです。

免責事項(リンゴとオレンジを比較していると思われないために): Fortinetもまた、大規模なバグ(FortiOS 7.2/7.4/7.6におけるConserve Modeやメモリリークなど)と闘っていること、そしてSophosも過去に深刻なCVEを抱えていたことは十分に承知しています。しかし、現在のv21.5/v22という段階において、この特定の状況こそが私たちにとっての痛手なのです。一方のベンダーでは絶え間ないCVEのパッチ適用に追われ、Sophosでは安定性の問題によって引き起こされる無駄な運用作業に追われているのです。

バージョンのコンテキスト(要約)

私がホコリを被った古いv19について書いているのではなく、多くの人が現在「最新」として実行しているものについて書いていることを明確にしておきます。

  • SFOS 21.5 GA (2025年6月2日): リリースノート: SFOS 21.5
  • SFOS 21.5 MR2 (Build 323, 2026年2月18日): リリースノートによると、この期間における最新の21.5です。
  • SFOS 22.0 GA (2025年12月) および v22 GA Re-Release (Build 411, 2026年1月20日): リリースノート: SFOS 22.0

これらはGA(一般提供)版およびメンテナンスリリースであり、ランダムな「ナイトリービルド」ではありません。

この比較が単なる感覚に基づいたものではないことを確認するために、簡単な現実チェックをしてみましょう。

Fortinet: 2025年11月以降のFortiOS CVE(2026年2月26日現在)

期間: 2025年11月1日〜2026年2月26日(公開日)。ソース: Fortinet PSIRTアドバイザリ(PSIRT概要)。

ここでは意図的に「Fortinetのすべて」をリストアップするのではなく、この期間におけるFortiOS/FortiGateに関連するアドバイザリのみをリストアップしています。なぜなら、実際にはそれが痛手だからです。パッチを適用し、計画し、テストしなければなりません。

CVSSスコアがすべてではありませんが、運用のコントラストを明確にします。5.xの「中」レベルは計画的に対応できることが多いですが、9.xのレベルになると、たちまち「すべてを投げ出してパッチを当てる」シナリオになります。

2026年2月10日公開(同日に複数のアドバイザリ)

  • FG-IR-25-667 (CVE-2025-55018, CVSSv3 5.2): FortiOS GUIにおけるリクエストスマグリング。これには「ログに記録されないリクエスト (unlogged requests)」が含まれるため、不快な問題です。
  • FG-IR-25-795 (CVE-2025-64157, CVSSv3 6.7): CAPWAPファストフェイルオーバーモードにおけるフォーマット文字列の問題(Admin/Configがトリガーとなる)。
  • FG-IR-25-1052 (CVE-2026-22153, CVSSv3 7.5): Agentless VPN/FSSOにおけるLDAP認証バイパス(実際の運用でよく用いられる回避策: LDAPサーバー上で認証なしのバインドを無効にする)。
  • FG-IR-25-934 (CVE-2025-68686, CVSSv3 5.3): SSL VPNシンボリックリンクの永続性パッチのバイパス。コンテキストとして重要: アドバイザリによると、ファイルシステムレベルでの別の脆弱性を介した事前の侵害が必要です。
  • FG-IR-25-384 (CVE-2025-62439, CVSSv3 3.8): FSSO Terminal Services Agentにおけるポリシーバイパス(修正にはFortiOSバージョンとTS Agentの最小バージョンの組み合わせが必要)。

2026年1月

  • FG-IR-26-060 (CVE-2026-24858, CVSSv3 9.4)、2026年1月27日公開: 管理FortiCloud SSO認証バイパス。アドバイザリでは、野外での悪用 (exploitation in the wild) と具体的な対策についても説明されています。
  • FG-IR-25-084 (CVE-2025-25249, CVSSv3 7.4)、2026年1月13日公開: cw_acd デーモンにおけるヒープベースのバッファオーバーフロー (FortiOS/FortiSwitchManager)。

2025年12月9日公開

  • FG-IR-25-647 (CVE-2025-59718, CVE-2025-59719, CVSSv3 9.1): 細工されたSAMLメッセージによるFortiCloud SSOログイン認証バイパス(デフォルトで必須の機能ではありませんが、実際の環境で使用されています)。
  • FG-IR-25-411 (CVE-2025-62631, CVSSv3 5.3): SSL VPNにおける不十分なセッション期限切れ(セッションの有効期間/パスワード変更のエッジケース)。
  • FG-IR-24-268 (CVE-2024-47570, CVSSv3 6.3): 機密情報がREST APIログに記録される(REST APIログ記録が有効な場合)。
  • FG-IR-24-133 (CVE-2024-40593, CVSSv3 5.9): 秘密鍵が管理者によって読み取られる可能性がある(鍵管理のエラー。パッチレベルで修正可能)。

2025年11月18日公開

  • FG-IR-25-358 (CVE-2025-53843, CVSSv3 6.9): CAPWAPデーモンのスタックバッファオーバーフロー。
  • FG-IR-25-632 (CVE-2025-58413, CVSSv3 6.9): 別のCAPWAPデーモンのスタックバッファオーバーフロー。
  • FG-IR-25-545 (CVE-2025-54821, CVSSv3 1.8): SSH経由での信頼されたホスト (Trusted hosts) のバイパス(CLIのエッジケース)。

はい、これは多いです。そしてはい、これらはプロセス(パッチウィンドウ、ステージング、変更管理、メンテナンスウィンドウ)で管理できます。

そして、コインの裏側がやってきます。

Sophos: 見出しにはならないが、運用は火の車

Sophosについても、もちろんセキュリティについて話をします。しかし、現在本当に私たちの時間を奪っているのは、単なるバグなのです。

ファイアウォールが問題を引き起こし続けているという理由だけで、現在社内には不必要な作業が山ほどあります。そしてある時、あなたは自分自身に、実際には不条理な問いを投げかけていることに気づくでしょう。

セキュリティの脆弱性はあるが安定して動作するファイアウォールと、CVEの大きな見出しはないが再起動後に立ち上がらないファイアウォール、どちらがマシだろうか?

これは学術的な議論ではありません。これは運用 (Operations) の問題です。悲しいことに、私は今、ありふれたバグのせいで顧客のネットワークが数時間完全にダウンしてしまうことよりも、いつか悪用されるかもしれない理論上のセキュリティ脆弱性の方を、ほぼ選んでしまいそうになっています。

現在の私たちの悩みの種(そう、すべて同時に起こっています)

はっきりさせておきたいのですが、これらは過去数ヶ月間に異なるシステムで何度も経験したバグに過ぎません。運用がプロジェクトに変わってしまうと、それはただただ疲弊し、フラストレーションが溜まるものです。特に、再びSophosサポートのメリーゴーランドに乗せられ、彼らがまるで「全世界でこの問題に直面しているのはあなただけです」と装うのが好きな場合はなおさらです。いいえ、私たちは違います。

  • ファイアウォールが再起動後に正常に起動しないことがある。
  • HAクラスターが崩壊するか、スプリットブレインのように振る舞う。
  • ログ記録が突然信頼できなくなる(または完全に消える)。
  • Let’s Encryptの証明書が更新されず、夜間に手動で対応しなければならない。
  • インターフェースが欠落するか、突然GUIに表示されなくなる。
  • SSDが故障する(ハードウェアの破損)。
  • WebAdminログインが完全にストライキを起こす – ログインできなくなり、多くの場合、再起動するしか解決策がない。
  • インターフェースが突然設定から完全に消え去る。
  • ログディスクがいっぱいになり、エラーメッセージが表示されたり、影響を受けるサービスが直接停止したりする。

コミュニティの反応(あなたは一人ではありません!)

Sophosコミュニティ(2026年初頭時点)を見回してみると、品質低下の状況は悲しいことに私たちの経験と一致しています。私たちの問題に加えて、他のユーザーはv21.5 / v22でさらに深刻なショーストッパーに遭遇しています。

  • 壊れたSSL VPNプロファイル(v22.0 Build 411): 一部のユーザーは、最新のv22にアップグレードした後、SSL VPNプロファイルの作成に失敗すると報告しています。新しいバージョンはバグが多すぎるため、彼らはv21.5にロールバックしなければならないことがありました。
  • 壊れたSNAT / Webサーバーアクセス(v22.0 Build 365): アップデート後、外部から内部Webサーバーへのアクセスが切断されたという報告があります。多くの場合、SNATがデフォルトのMASQオプションに手動でリセットされるまで、インターネットルーティングは完全にストライキを起こします。
  • CLIスパム / “Invalid rule id”: “Invalid rule id or family for update” のような警告がコンソールに大量に表示されます。(これは「単なる」表示エラーのようですが、無意味にログを溢れさせます)。

そして、これらすべてにおいて最も苦いのは、これらの一つ一つが単に煩わしいだけでなく、重大なリスクであるということです。ログが欠落していれば、盲目飛行をしているのと同じです。HAが不安定であれば、フェイルオーバーへの信頼を失います。証明書が更新されなければ、回避策 (workarounds) を構築することになります。そして、回避策は後々のインシデントの温床となるのです。

Sophosのバグ(v21.5からv22): あなたの症状に直撃するもの

管理者であるあなたがこれを明確に追跡できるように、公式のリリースノートまたは公式に文書化された既知の問題 (Known Issues) から特定のNC-IDをここで意図的に挙げておきます。

要約: 症状 -> ノートに書かれていること

運用中の症状Release Notes / Known Issues の例
起動/再起動が正常に行われないNC-151715, NC-152641, NC-123910
HAが不安定、またはフェイルオーバー時にパニックになるNC-142962, NC-132291, NC-147307, NC-147739, NC-149039
ログ/レポートが消えた、または信頼できないNC-158526, NC-160962, NC-157663, NC-169237, NC-135594, NC-175936, NC-170292, NC-166381
Let’s Encrypt/WAFがストレスを引き起こしているNC-148937, NC-152022, NC-140663, NC-141062, NC-152540, NC-146082, NC-159041
Entra SSO/Captive Portal/VPN Portalの動作がおかしいNC-167126, NC-157635, NC-167130, NC-167128
VPN/IPsecが立ち上がらない、または相互運用性が壊れるNC-136352, NC-128116
明確なルールが原因ではないトラフィックのドロップNC-169842(アップグレード後はIPS/Snortも原因として考慮)
インターフェースが「見つからない」(UI)既知の問題: 末尾が10桁以上の数字で終わるインターフェース名は、WebAdminビューでインターフェースを非表示にします

運用現場からの苛立たしいストーリー

私たちは朝そこに座って、いつもしていることをします。チケットの処理、変更の計画、監視の確認。

そしてファイアウォールは、ノックもせずにドアを叩きます。

CVEでなく、「Critical Advisory」でもなく。ただの日常茶飯事として。

最初のコーヒー、最初の再起動、そして頭に浮かぶ疑問。再び立ち上がるだろうか、それとも?

うまくいけば立ち上がります。状況が悪ければ、「Failsafe」と「生きてはいるがトラフィックを処理していない」の間のどこかに着地します。本当にまたコンソールケーブルを取り出す必要があるのだろうかと考え続けている間に、次の章が始まります。

HA(高可用性)。あなたのエアバッグ。そして時には、駐車中にエアバッグが展開したような気分になります。

次にログ記録。私たちは皆知っています。何が起こっているのか見えなければ、それを制御することはできません。そして突然ログが欠落し、レポートは空になり、またはサービスが終了を告げます。あなたはそこに立って、現在セキュリティの問題があるのか、データ品質の問題があるのか、あるいはその両方なのかを自問します。

そして、最大の障害がやってきます。WAF、リバースプロキシ、Let’s Encrypt。

あなたは派手なことをしたいわけではありません。ただ証明書が更新され、午前2時13分にWebサイトが “connection refused” と叫ばないようにしたいだけです。

おまけに、インターフェースが「消え」ました。本当に消えたわけではなく、UI上で消えただけです。トラフィックは動いているかもしれませんが、デバッグに必要なものが見えません。

ある時点で、あなたは実際には不条理なこの質問を自分自身に投げかけます。

セキュリティの脆弱性はあるが安定して動作するファイアウォールと、大規模なCVEの見出しはないが、運用上、毎週私の床に新しい穴を焼き開けるファイアウォール、どちらがマシだろうか?

1) 起動、再起動、アップグレード: 「生きてはいるが、働いていない」

再起動後にファイアウォールが正常に起動しない場合、それは単なる「アップタイム」の問題ではありません。そのような状況では、普段なら絶対にやらないようなことをしがちになるため、これは1日の損失に加えてリスクが伴います。

SFOS 21.5のリリースノートからのいくつかの例:

  • 再起動中のFailsafe: NC-151715 (Firmware Management): Auxiliaryデバイスが再起動中にFailsafeになりました。再起動に失敗しました。
  • アップグレード後にトラフィックが停止: NC-152641 (Firmware Management): アップグレード(21.0 MR1 Build 237から)後、トラフィックが処理されなくなりました(SWAPメモリ構成の変更)。
  • カーネルパニック: NC-123910 (Firewall): カーネルパニックの問題。

そしてそうです。SFOS 22.0は追加のアップグレード要因をもたらします。Sophosはリリースノートで、v22はアーキテクチャの変更をもたらし、まれに追加の手動手順が必要になる可能性があると指摘しています。これはまさに、運用において痛手を負う、アップグレードのエッジケースです。

2) HA: 駐車中に展開するエアバッグ

HAはあなたの安全網です。だからこそ、エッジケースがまさにそこでエスカレートすると、非常に痛いのです。

SFOS 21.5 リリースノートより(抜粋):

  • 同時再起動時にHA Event Trackingが停止する: NC-142962 (HA)。
  • パッシブノードへのファームウェアのアップロードがハングする: NC-132291 (HA)。
  • フェイルオーバーがRestart Loopを引き起こす: NC-147307 (HA)(ノートには、例えばXGS 2300と明記されています)。
  • 停電後に同期が失敗する: NC-147739 (HA)。
  • HAステータスがフラップし、専用リンクでCrash Dumpが発生する: NC-149039 (HA)。

3) ログとレポート: 盲目飛行している時

私にとって、これが「バグ」が単なる「運用」ではない本当の理由です。ログ記録/レポートが不安定な場合、それはセキュリティ上の問題です。

SFOS 21.5 リリースノートより(抜粋):

  • ログ記録/レポートが散発的に停止する。Garnerで頻繁にcoredumpが発生する: NC-158526 (Logging Framework)。
  • Garnerと fwcm-heartbeatd が停止する: NC-160962 (Logging Framework)。
  • アップグレード後: レポートがなくなる: NC-157663 (Logging Framework)。
  • データベースの破損によりLog Viewerがイベントを失う: NC-169237 (Logging Framework)。
  • Syslogのファイル記述子 (fd) の破損。データが間違ったFDに送信される: NC-135594 (Logging Framework)。

さらに、Sophosの既知の問題リスト (KIL) には、日常生活で同様に苦痛を伴ういくつかの項目が見つかります。

  • ログビューアに新しいデータが表示されない(active.dbが欠落している): NC-175936 (Logging Framework)。一部の21.5.1システムでは、/tmp/eventlogs/ の下の active.db が欠落している場合があります。その場合、トラフィックとセキュリティ機能は実行され続けているにもかかわらず、ログビューアは「フリーズ」します。KILによると、これはv22で修正されており、21.5 MR2の修正に含まれるはずです。
  • HAでの誤検知 “advanced threat detected”(高度な脅威が検出されました): NC-170292 (Logging Framework)。Sophos Centralは、HA展開においてアラートを送信し、説明に生のログを含めることができます。KILによる回避策: Garnerサービスを再起動します。KBA: https://support.sophos.com/support/s/article/KBA-000043672
  • ReportDB_v9がSTOPPEDと表示される(劇的に見えますが、そうではありません): NC-166381 (Reporting)。v21.0 GA以降にアップグレードした後、非常に特定の期間が経過すると、サービスはSTOPPEDとして表示されます。KILによると、これは予想される動作であり、v21より前のレガシーレポートにのみ影響するため、運用上の影響はありません。

そしてここで「Sophos Central ファクター」が登場します。CentralをSingle Pane of Glass(単一の管理画面)として使用している場合、ログの問題は二重の痛みを伴います。ローカルのログパイプライン(Garner/DB)が倒れると、Central Firewall Reporting (CFR) へのアップロードも失敗するかハングする可能性があります。そして、いずれにせよCFRは常に「リアルタイム」ではありません。つまり、最悪の場合、ローカルログが不足しているだけでなく、日常生活で実際に依存したかったまさにその中央のビューが不足しているということです。

4) WAFとLet’s Encrypt: 公共サービス、ただしドラマはご免だ

証明書が更新されず、リバースプロキシが暴走した場合、それは「小さなバグ」ではありません。それは直接的なCustomer Impact(顧客への影響)です。

SFOS 21.5のリリースノートには、WAF/Let’s Encryptに関する問題のファミリー全体が記載されています。

  • Let’s Encryptの証明書作成に失敗する: NC-148937 (WAF)。
  • 自動ファイアウォールルール (Auto-Firewall-Rule) がないため、LEリクエストが失敗する: NC-152022 (WAF)。
  • 無効なLE設定により、リバースプロキシが絶えず再起動する: NC-140663 (WAF)。
  • ACMEがIPアドレスに証明書を発行しない: NC-141062 (WAF)。
  • WAFルールが自動的にオン/オフを切り替える: NC-152540 (WAF)。

そして、「バグのように見えるが、セキュリティのトレードオフである」というトピックがあります。KILからの例:

  • URLにエンコードされたスラッシュ (%2F) が含まれている場合、WAFは404を返す: NC-159041 (WAF)。アプリがURLでエンコードされたスラッシュを使用している場合、Apacheはデフォルトでこれをブロックします(ディレクティブ AllowEncodedSlashes のデフォルトは No です)。バックエンドは「実際には」そのパスを持っていますが、404が表示されます。背景: エンコードされたスラッシュは、パスの制限をバイパスする可能性があります(典型的な例: .../something%2F..%2Fadmin)。詳細: https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes

そして、それが現場でどのように見えるかを知りたい場合は、このコミュニティのスレッドで、ある人が21.5.xにアップグレードした後、自動更新証明書が「なくなり」、WAFが起動せず、Webサイトが ERR_CONNECTION_REFUSED で死んだと説明しています。最終的な解決策は、Webプロテクションルールのクリーンアップと壊れたLE CSRの削除であり、その後再び機能するようになりました。(スレッド:アップグレード後のWAF/Let’s Encryptエラー、ERR_CONNECTION_REFUSED)。

場合によっては、それは「バグ」でさえないこともあります。それはプロセスの問題です。Sophosコミュニティでは、WebAdminでLet’s Encryptの利用規約 (Terms of Service) が期限切れとマークされ、再度同意しなければならないケースもありました。(スレッド:Let’s Encrypt Terms of Service have expired)。

既知の問題リストからの別の「アップグレードの罠」の典型的な例:CAストアに新しく導入されたLet’s Encrypt証明書と同じ名前のオンボード証明書がすでにある場合、アップグレードが失敗する可能性があります(NC-146082)。

5) 「インターフェースが見つからない」(または単に非表示になっている)

これはリリースノートでは退屈に聞こえますが、実際には盲目飛行を強いるようなバグです。

Known Issueとして公式に文書化されています:

SFOS 21.5 GA以降の物理または論理インターフェースに10桁以上の数字で終わる名前(ノートの例: VLAN_1234567890)がある場合、WebAdminのNetwork > Interfacesの下で物理インターフェースが表示されなくなるか、論理インターフェースを展開できなくなります。重要: リリースノートによると、機能は影響を受けず、WebAdminコンソールでの表示のみが影響を受けます。

ここまでの小括: 起動/アップグレード、HA、ログ/レポート、WAF/Let’s Encrypt、そしてUIでさえも、同時にあなたをつまずかせます。ここからは、最初は「ネットワークの詳細」のように見えますが、運用上は同じくらい高くつくトピックが続きます。Entra SSO、VPNの相互運用性、一見ランダムなトラフィックのドロップなどです。

6) ID/SSO (Entra) と Captive Portal: アクセスが「ランダム」に見える時

これは運用において特に陰湿なバグのカテゴリです。ユーザーにとっては「アカウントの調子がおかしい」ように見えます。あなたにとっては「それは単にSSOの問題だ」と見えます。実際には、間にファイアウォールがあることが多いのです。

Microsoft Entra ID (Azure AD) がミックスに含まれている場合の、KILからのいくつかの未解決のトピック:

  • Sophos Connect VPN: Conditional Access(条件付きアクセス)が完全にサポートされていない: NC-167126 (Authentication)。初回ログイン時の最初のMFAチャレンジの後、それ以降の接続ごとに条件付きアクセスチェックが必ずしもトリガーされるとは限りません。KILによると、ユーザーがSophos Connectクライアントで手動でログアウトするまで、ポリシーの適用は再実行されません。
  • VPN SSO: UPNとメールアドレスが異なると、ログインが壊れる: NC-157635 (Authentication)。Entraの電子メールIDとUPNが異なる場合、ユーザーはVPNポータルにはアクセスできますが、SSL VPNまたはIPsecポータルにはアクセスできません。KILによる原因: OAuthヘッダーは電子メールを提供し、それは後にUPNとして解釈されます。
  • Captive Portal: Entra SSOユーザーはルールにPrimary Group(プライマリグループ)を必要とする: NC-167130 (Authentication)。インターネットアクセスは、ファイアウォールルールの照合でプライマリグループを使用した場合にのみ機能します(ここではセカンダリグループはカウントされません)。KILによる修正は「次のメンテナンスリリース」で行われます。回避策: プライマリグループを明示的に照合するか、ユーザーベースのルールを使用します。
  • Entra SSOでの時折の “no permission”(権限なし)エラー: NC-167128 (Authentication)。Entra ID AuthとオンプレミスのAD Authが並行して使用されている場合(トークンの再利用)に発生する可能性があります。KILによる回避策: ブラウザのCookieをクリアするか、Sophos Connectクライアントで「強制再ログオン」します。または、1つの認証方法を一貫して使用します。

7) VPN/IPsecの相互運用性: アップグレードは多くの場合「相手」のせいで失敗する

21.5で始まったわけではないが、現場に古いクライアントやリモートノードがある場合、21.5/v22でも引き続き関連する2つのKILトピック:

  • IPsec IKEv2: トンネルが立ち上がらない(フラグメンテーション/PMTU): NC-136352 (IPsec)。20.0 MR1以降、デフォルトのIKEv2プロファイルは、より大きなパケット(より多くのデフォルトフィールド)を生成でき、時には1500バイトを超えることもあります。パス上のフラグメンテーション/PMTUが不十分な場合(フラグメントがドロップされる場合)、S2Sトンネルは起動しません。KILによる緩和策: IPsecプロファイルでDHグループを減らす(最小4)、またはリモートピアで使用されているグループを正確に設定します。
  • SSL VPN/OpenVPN 2.6.0: EoLクライアント/UTM9との非互換性: NC-128116 (SSLVPN)。20.0 MR1以降、OpenVPNは2.6.0になっています。これにより、古いSFOSバージョン(18.5以前)、レガシーSSL VPNクライアント(EoL)、UTM9 OSなどとのサイト間SSL VPNが切断されます。KILによる推奨事項: 両側をアップグレードするか、IPsec/REDに切り替えます。リモート: Sophos Connectまたは現在のOpenVPNクライアントを使用します。

8) ルールヒットなしのトラフィックドロップ: 厄介な原因としてのAccurate ECN

トラフィックが「ランダムに」ドロップしているように見える場合、最初にチェックするのはルール、IPS、TLSインスペクション、ルーティングです。そして、ファームウェアのアップグレード後、リストにクラシックなケースが加わります。IPSエンジン (Snort) またはシグネチャがより厳格になり、正当なトラフィックをブロックし、ログですぐに明確なイベントが見つからない場合です。その後、最終的にはポリシーまたはチューニングの作業であるにもかかわらず、何時間も「ルーティング」または「ルール」のデバッグに費やすことになります。

しかし、KILには、レーダーに載せていないと非常に長い間あなたを忙殺させる可能性のある候補も存在します:

  • Accurate ECN Bitsによりトラフィックがドロップされる: NC-169842 (Firewall)。Accurate ECNはTCPビット (ECE/CWR/NS) を異なる方法で設定します (RFC 7560)。KILによると、カーネルはこれを「予約済みビットセット (reserved bit set)」として解釈し、トラフィックをドロップします。原因を絞り込むには、クライアント側を確認することが役立ちます。実際には、これは新しいLinuxカーネルやAppleクライアントで目立つ可能性があります。なぜなら、これらはRFC 7560/Accurate ECNをより積極的に使用する傾向があるからです(「なぜMacBookだけが蹴り出されるのか?」)。RFC: https://www.rfc-editor.org/rfc/rfc7560

9) v22 GA Re-Release Build 411: そもそもなぜそれが必要だったのか

2026年1月20日、Sophosは「まれで孤立した問題」を修正するために、v22 GAを再リリース(Build 411)としてプッシュしました。このリストは、「変更ウィンドウでの不必要な作業」のベストヒット集のように読めます(出典:Re-Releaseに関するSophosコミュニティのブログ投稿):

  • NC-171003: VLANフィルタリングを使用したBridgeインターフェース経由でWebAdminにアクセスできない。
  • NC-170987: CLIスパムログ “Invalid rule id or family for update”。
  • NC-170970: DNATルールに特定のアウトバウンドインターフェース (outbound interface) がある場合、DNATトラフィックが失敗する。
  • NC-171600: SSL/TLSウィジェットとセッションチャート (Session Chart) データが正しくない/空である。
  • NC-172197: SNMP構成を追加できない。

ブログ投稿: v22 GA re-release (Build 411) is now available.

本当の損害: バグはセキュリティのコストを押し上げる

重要なのは、「バグはCVEより悪い」とかその逆とか、そういうことではありません。

重要なのは、運用基盤が不安定になると、セキュリティは自動的に低下するということです。

  • 次のデグレバグ (Regression-Bug) が怖くて、アップグレードを遅らせる。
  • ストレスの原因になるため、機能(「今は必要ない」)を無効にする。
  • 可観測性(ログ)を失い、それは対応の遅れを意味する。
  • セグメンテーション、バックアップ、クリーンなルールの作成ではなく、火消しに時間を投資する。

そして、実際には完全に過小評価されている点が1つあります。それは Time-to-Resolution(解決までの時間) です。CVEの場合、通常はアドバイザリ、緩和策、パッチがあります。バグの場合、立証責任はすぐに管理者に降りかかります。tcpdump、CTRログ、Advanced Shellのエクスポート、「再起動してみましたか?」 - 本番環境が燃えている間に。そしてその後に初めて、サポートのメリーゴーランドに乗ることになります。エスカレーション、ホットフィックスまたは次のMRの待機。これにより、予定していなかった追加の運用時間が消費されます。

そしてまさにそれが、「脆弱性があっても安定している方が良いのでは?」という質問が人間的でありながら、実際には行き止まりである理由です。

「脆弱性」だけがセキュリティの問題なのではありません。「不安定なファイアウォール」もまた、セキュリティの問題なのです。

私たちがこれから学ぶこと(事態を完全にエスカレートさせないために)

毎週車輪の再発明をすることなく、狂気を制限するのに役立ついくつかのこと:

アップグレードの飛行前チェック (Upgrade-Preflight)(始める前に)

  • バックアップを復元 (Restore) のように扱う: 構成をエクスポートし、オフラインでバックアップし、少なくとも1回はテストされた復元を用意する。
  • HAステータスの「緑」だけでは不十分 – フェイルオーバーをテストしてください! GUIによると、私たちの同期 (Sync) はOKで、ハートビート (Heartbeat) もクリーンでした。しかし、緊急時には、Auxiliary Appliance(補助デバイス)はやはりフェイルオーバーをスムーズに引き継ぎませんでした。WebAdminの緑色のチェックマークは、現在、変更ウィンドウ中に機能することを悲しいことに保証するものではありません。
  • ログの確認: 外部Syslog/Collectorがイベントを受信しているか、ギャップがないか、時間/NTPが正しいか。
  • 証明書/WAFの確認: 有効期限、Let’s Encryptの検証、プランBとしてのフォールバック証明書。
  • 本当にSSO/VPNをテストする: Entraログイン、Captive Portal、Sophos Connect、SSL VPN、IPsec S2S(フェイルオーバーを含む)は、それ自体がテストケースです。
  • Break-Glass(ガラスを割る)の準備: コンソール/帯域外 (Out-of-band) アクセス、ローカル管理者、ロールバック用のファームウェアイメージ。
  • デュアルブート (Dual-Boot) を忘れない(そして過大評価しない): Sophosには2つのファームウェアパーティションがあります。アップグレードがうまくいかなかった場合、21.5へのロールバックは多くの場合、再起動して別のパーティションを選択するだけです。しかし、2番目のパーティションも正常に起動せず、完全に再イメージング (Reimage) するしか解決策がないケースもあります(サポートはこれを非常に早く要求する気がします)。そして、Reimageでさえ常に根本原因を解決するわけではありません。

アップグレード中(HAが関与している場合)

  • 最初にパッシブ/セカンダリ、次にフェイルオーバー、そしてアクティブ。
  • 各ステップの後に簡単に検証する: トラフィック、VPN、DNS、ログ、WAF/リバースプロキシ

日常の運用において

  • HAを単に構成するだけでなく、テストする: フェイルオーバードリルと、クラスターを分割するタイミングに関する明確な基準。
  • ログ記録を製品として扱う: ログのギャップに対するアラート、Service Health、UIがおかしくなった場合に備えてCLI経由での緊急エクスポート。
  • 証明書を積極的に監視する: 更新は「あれば便利 (nice to have)」ではなく、運用上のリスクです。ToSの変更は変更 (Changes) のように扱います。
  • Health Checkはヒントとして扱い、KPIにはしない: v22で、Sophosはヘルスチェック (Health Check) を導入しました(詳細は私の記事 Sophos Firewall v22 Health Check - 完全な概要 を参照)。ベストプラクティスのチェックリストとしては良いのですが、時には「エコシステムのスイッチを緑色にする」だけのように感じることがあります。実際の例: 多くの人が、ヘルスチェックで緑色のチェックマークを得るためだけに、ログイン時の免責事項を有効にしています。しかし、私がそこで欠けていると感じるのは、「ログ/レポートDBは正常か?」や「SSDのステータスはどうなっているか?」といった、ハードな運用指標です。特に一部のアプライアンスでは、予想よりも早くストレージの問題が発生しているからです。

結論: ツールがリスクになる時

一日の終わりに、私たちは皆同じ船に乗っています。私たちは重要なインフラストラクチャを管理しており、私たちを混乱から守るはずのツールが、ツール自身が混乱を引き起こさないと信頼できなければなりません。現在のファームウェアの品質(v21.5 / v22)を考えると、Sophosは間違いなく多くの宿題を抱えています。「安定したリリース」に対する信頼は、私たちやコミュニティの多くの人々にとって、深刻な打撃を受けています。

私は「安全か安定かのどちらか」であるファイアウォールは望んでいません。私は、その両方を兼ね備えたファイアウォールを望んでいます——いや、必要としています。

Sophosがこれらの品質の欠陥を制御できるようになるまで、私たち運用側には1つの選択肢しか残されていません。さらに規律正しくなり、UIの「緑色のチェックマーク」を気にすることをやめ、導入計画において、ありふれたバグをクリティカルなCVEと同じくらい深刻に受け止めることです。

次回まで、
Joe

ソース

© 2026 trueNetLab