CVE-2026-98432: Ubuntu VPS を確認し、露出を減らしてください

#3 11 月 2026 の更新

11 月 3 に、公式の Ubuntu 修正を両方の VPS インスタンスにインストールしました。再起動して新しい SSH アクセス、HTTPS サイト、テストされたアプリケーションを確認した後、カーネル 7.0.0-43-generic を実行しています。これらのパッケージは、提案されたものから提供されています。これは、Ubuntu が一般的な認定または安定したチャネルを介した配布を完了したことを意味するものではありません。外部依存関係は利用できないままです。アプリケーションの完全な回復はまだ検証する必要があります。

以下のセクションでは、30 10 月の緩和策について説明します。 3 11 月のフォローアップでは、対象となるインストール、再起動後のチェック、緩和策から修正プログラムのインストールまでの 4 日間と Ubuntu のエントリが公開されてからの 19 日間の区別について詳しく説明します。

3 11 月のフォローアップと両方の VPS の結果を読む

Ubuntu の 2 11 月のお知らせを読む

現在の Ubuntu ステータスを確認する

#まずは VPS を確認してください

これらのコマンドは、実行中のカーネル、ディストリビューション、2 つのネットワーク設定、およびリッスンしている MPTCP ソケットを識別します。構成は変更されません。 ss のバージョンに MPTCP サポートがない場合、エラーはサーバーが保護されていることを意味しません。

結果をディストリビューションのセキュリティ トラッカーと比較します。ソーシャル メディアの投稿からコピーしたカーネル バージョンでは十分ではありません。ディストリビューションは修正を独自のパッケージにバックポートできます。インストールされたパッケージは、必ずしも現在実行中のカーネルであるとは限りません。

uname -r
cat /etc/os-release
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
sudo ss -M -l -n -p

#2 つの VPS インスタンスで変更した点

10 月 30 日に、2 つの Ubuntu VPS インスタンスを監査し、対象を絞った一時的な対策を適用しました。 IP オプションを運ぶ IPv4 TCP パケット用の専用フィルターを追加し、関連するネットワーク名前空間での MPTCP ソケットの作成を無効にしました。

1 つの Caddy サービスには、調整された設定でソケットを再作成するための制御された再起動がありました。 5 つの既存のコンテナーは、プロセスと開始時間を維持しました。次に、新しい SSH 接続をチェックし、テストした 7 つのサイトすべてから HTTPS 200 応答を受け取りました。

オペレーティング システムをアップグレードしたり、VPS を再起動したりしませんでした。これらの結果は、介入後の私たちのチェックを説明しています。考えられるすべての悪用経路がブロックされていることを証明するものではありません。

#別のルールセットを使用して IP オプションをフィルタリングする

これは、テーブル名の例を使用したフィルターの構造です。最初のルールはログ記録を制限します。 2 番目の場合は、制限に達した後でも、一致するすべてのパケットをドロップします。 IP オプションは、MSS や SACK などの通常の TCP オプションとは異なります。

これを、回復アクセスと範囲指定されたロールバックの準備ができている状態で、既存のファイアウォールを確認して統合する例として扱います。構成全体を置き換えないでください。セキュリティラベル付けに使用される IP オプションなど、特別なネットワーク要件を確認してください。

このフィルターは IPv4 をターゲットとしています。私たちはこれを露出の削減と表現していますが、脆弱性を完全にカバーするという保証はありません。

table inet cve_2026_98432 {
  chain prerouting {
    type filter hook prerouting priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 limit rate 5/minute burst 5 packets log prefix "CVE98432 IPopts " level warn
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

#MPTCP を使用しない場合は無効にします

サービスが MPTCP を必要としない場合、この設定により、現在のネットワーク名前空間で新しい MPTCP ソケットが作成されなくなります。すでに開いているソケットは閉じません。ソケットを再度確認し、影響を受けるサービスのみの再起動を計画します。

起動時にこの設定を維持するには、既存の設定を確認した後、専用の sysctl.d ファイルに net.mptcp.enabled = 0 を追加します。その後、計画された再起動中に永続性をテストする必要があります。

sudo sysctl -w net.mptcp.enabled=0

#Goで書かれたサービスもチェックしてみよう

Go 1.24 は、サポートされているシステムの ListenConfig に対してデフォルトで MPTCP を有効にしました。したがって、Go で作成されたリバース プロキシは、アプリケーションが Node.js を使用している場合でもチェックする価値があります。

以下の設定は、サービス環境で提供されるときのデフォルトを変更します。他の GODEBUG 値を保持し、影響を受けるプロセスのソケットを再作成します。 Caddy に使用しました。カーネル修正を置き換えるものではありません。

GODEBUG=multipathtcp=0

#Docker: ホスト設定はチェックの一部にすぎません

MPTCP 設定は、各ネットワーク名前空間に属します。したがって、ホスト上のゼロ値は、すべてのコンテナーが同じ構成を持つことを確立するものではありません。

既存の名前空間をチェックし、新しい名前空間の定期的なチェックを追加しました。アクティベーション後に作成された名前空間を使用したテストで、処理されることを確認しました。このチェックは定期的なものであるため、適用されるまでに遅延が生じます。これが、ホストの入口でフィルタリングを続ける理由の 1 つです。

以前に開いた内部コンテナ ソケットの一部が残る場合があります。システム設定をすべてのソケットが消失した証拠として扱うのではなく、それらのソケットをパブリック リスナーから区別しました。

#軽減策を確認した方法

フィルタがロードされていることを確認し、そのカウンタを検査し、MPTCP 設定とリスナーを確認しました。非エクスプロイト診断パケットにより、ドロップ ルールに達したことが確認されました。エクスプロイトコードは実行しませんでした。

また、新たに SSH 接続を開き、外部からサイトをチェックしました。既存のファイアウォール ルールは維持されました。永続化メカニズムは構成され、リロードされましたが、VPS の完全な再起動後にはテストされませんでした。

カウンタが増加すると、パケットがルールに一致したことが証明されます。これは、侵入の試みや完全な保護を証明するものではありません。弊社独自の診断チェックによって、その可能性が高まることもあります。

#次へ: パッチを当てたカーネルで起動する

ディストリビューションの公式修正が引き続き優先されます。システムで使用できるようになったら、そのインストールと必要な再起動を計画し、実際に実行中のカーネルを uname -r で確認します。公式ステータスとサービスの要件に基づいて、一時的な措置を解除するかどうかを決定します。

この作業は、アプリケーションをホストする Linux インフラストラクチャに関係します。 npm から PRNext へのアップデートでは、VPS カーネルにパッチを適用できません。セルフホスティングは、システムのこの層に従い、実際のサービスに対して変更をチェックすることも意味します。

次をお読みください: VPS へのアプリケーションのデプロイ