セキュリティコミュニティ「WEST-SEC」

セキュリティ初心者の方でも参加できる「わかりやすい」セキュリティイベント、8割解けるCTFを開催しています。

FortiGateにおけるSSL-VPN機能の廃止について

1.概要

(1)概要

・FortiOS 7.6.3 以降、SSL-VPNトンネルモードが廃止され、リモート接続をするには、IPsec VPNを使う必要がある。
・これまでは、設定画面はあったが、FortiOS 7.6.3 からはGUI/CLIからSSL-VPNトンネルモードの設定自体が消失

(2)廃止の背景

・IPsecがOSのカーネルレベルで処理される標準化されたプロトコルであるのに対し、SSL-VPNは多くの場合、Webアプリケーションとして実装される。これにより、メモリ管理や入力検証におけるバグが致命的な脆弱性につながりやすい構造的欠陥を抱えていた。
・近年のセキュリティインシデントにおいて、FortiGateのSSL-VPN機能（sslvpnd）は、ランサムウェアグループや国家支援型攻撃者（APT）の主要な標的となってきた。特に、認証する前（＝認証せずに）に悪用可能なリモートコード実行（RCE）ができる脆弱性が発生し、その攻撃の被害が多発していることがある（詳細はこのあと）
・脆弱性の頻発でパッチ適用が負担に
https://xtech.nikkei.com/atcl/nxt/column/18/03373/101600001/

(3)詳細

・当初、FortiOS 7.4系列において、メモリ容量が2GB以下のエントリーモデル（FortiGate-40F, 60F等）を対象にSSL-VPN機能の削除が開始された 。しかし、FortiOS 7.6.3のリリースに伴い、この制限はすべてのFortiGateモデルに拡大された 。
・具体的には以下の変更が適用される：
❶SSL-VPNトンネルモードの完全削除
GUI（管理画面）およびCLI（コマンドライン）の両方から設定項目が排除される。
❷設定の継承不可
既存のファームウェアから7.6.3へアップグレードした際、既存のSSL-VPN設定は削除され、移行されない 。
❸Webモードの名称変更と縮小
従来の「SSL-VPN Webモード」は「Agentless VPN」へと名称変更されたが、これも2GBメモリモデルでは使用不可となり、機能的にも大幅な制約が課されている 。

■参考：エントリーモデル（2GBメモリ）での廃止が先行した理由
sslvpndプロセスが大量のメモリを消費し、システム全体の安定性を脅かす可能性があるため
(3)WEST-SECのイベントおよび本記事の目的

FortiGateのSSL-VPN機能の廃止が発表されました。現場でFortiGateを運用されている情報システム部さんは、以下の不安をお持ちかと思います。
・代替え策はどうすればいいのだろうか？製品を変えたらいいのだろうか
・IPsecなら安全なの？また被害にあったりしないの？
・IPsecに変更する場合、どうやって設定するの？細かいパラメータはどうする？

今回のWEST-SECでは、SSL-VPN廃止という事態を受け、今後のアクションに着目、さらに、主に技術面での解説をしていきます。

また、最近、ランサムウエアの被害が増えていますが、内部のラテラルムーブメントであったり、C＆Cサーバへの通信防御のために、FortiGateの設定を見直すことは非常に有効です。具体的には、中外への通信の強化（FW、IPS、URLフィルタ、アプリケーションコントロールなど）、ログの設定とアラートをしっかりするだけでも、ものすごく効果（防げる、または気づける）があります。攻撃を気づければ、被害を最小限にするためのアクションをうつことができます。そんな話も、イベントの中でお伝えしたいと思います。

(4)SSL-VPN機能の廃止に関すルニュース記事

xtech.nikkei.com

www.jbsvc.co.jp

xtech.nikkei.com

2.脆弱性と攻撃の被害

(1)UTMやFWでの脆弱性が頻発

FortiGate社に限らず、代表的な会社のUTMやFW、VPN装置にて、脆弱性の存在が確認されています。
（出典：令和６年９月 警察庁サイバー警察局 https://www.npa.go.jp/publications/statistics/cybersecurity/data/R6kami/R06_kami_cyber_jousei.pdf)

【参考記事】
・Fortinet 製 FortiOS の脆弱性対策について(CVE-2024-55591)
https://www.ipa.go.jp/security/security-alert/2024/alert20250115.html
・「Cisco ASA」狙うゼロデイ攻撃、5月に複数政府機関で確認
https://www.security-next.com/174973
・Ivanti製VPN製品の脆弱性、国内組織もゼロデイ攻撃の標的に　※Ivanti Connect Secureは、旧Pulse Connect Secure
https://www.security-next.com/152609
・Check Point機器のVPN機能に脆弱性、攻撃から判明 - アップデートを
https://www.security-next.com/157686
・Palo Alto Networks 製 PAN-OS の脆弱性対策について(CVE-2024-3400)
https://www.ipa.go.jp/security/security-alert/2024/alert20240415.html

(2)発表された脆弱性

SSL-VPNのデーモン部分に致命的バッファオーバーフロー（CVE-2024-21762）や認証バイパス脆弱性（CVE-2023-27997）などが立て続けに発見され、いずれもパッチ適用前の環境で攻撃に使われている

(3)ランサムウェア攻撃の感染ルート
ア 感染経路
ランサムウェアの感染経路について質問したところ、115件の有効な回答があり、このうち、ＶＰＮ機器からの侵入が73件で63％、リモートデスクトップからの侵入が21件で18％を占め、テレワーク等に利用される機器等のぜい弱性や強度の弱い認証情報等を利用して侵入したと考えられるものが約82％と大半を占めた。

（出典：令和6年3月14日 警察庁 https://www.npa.go.jp/publications/statistics/cybersecurity/data/R5/R05_cyber_jousei.pdf
(4)ニュースや報道発表

・2025年4月には米CISAも Fortinet のSSL-VPN脆弱性事例に言及し、修正パッチ適用までSSL-VPN機能を無効化するよう勧告した
・フランスCERT-FR も同様に被害を報告しており、グローバルに強い注意喚起がなされている
https://thehackernews.com/2025/04/fortinet-warns-attackers-retain.html#:~:text=The%20U,said%20it%27s%20aware%20of%20compromises

(5)攻撃を受けるとどうなるか

実演する？

3.代替え案（対処策）

3.1 ワークアラウンド

少なくとも、FortiOSを最新化した上での暫定対処です。
・VPN利用の廃止（保守作業は現地のみにする）
・利用時のみ稼働させる。（同時に、IPアドレスを確認し、そのIPアドレスからのみ接続許可をする）
・送信元IPアドレス制限。少なくとも、海外からの利用がないのであれば、海外通信は全てブロックでいいだろう

3.2 対処策

(1)全体像

・現状と移行後のプロトコルを整理します。

項目 従来のSSL-VPN IPsec VPN ZTNA
主要プロセス sslvpnd iked (IKE), カーネル (ESP) wad
攻撃対象領域（プロトコル） TCP 443 UDP 500/4500 TCP 443
(2)IPsecを使う

・必要なソフトウェア → 無料版FortiClient（VPN-only版）を使用すれば、ライセンス費用はゼロである。★これでいい？

(3)ゼロトラスト（ZTNA）機能

別途ライセンスが必要なはず　→ZTNAを利用するには、FortiClient EMSのライセンスが必須となる。
必要なソフトウェア
費用

(4)他社への移行

3.3 7. コスト比較

SSL-VPNは「ハードウェアを買えば無料」であったが、代替案への移行にはコスト構造の変化が伴う場合がある。
❶IPsec VPNのコスト（最安・維持費ゼロ）
IPsec VPN機能自体はFortiGateの基本機能であり、ライセンス費用は発生しない。
　・サーバー側: 無料（FortiGate本体に含まれる）。
　・クライアント側: 無料版FortiClient（VPN-only版）を使用すれば、ライセンス費用はゼロである。ただし、サポートがなく、設定の集中管理もできないため、数百人規模の展開では運用コスト（人件費）が増大する 。 　★この点はどうすべきか。

❷Universal ZTNAのコスト（有償・高機能）
ZTNAを利用するには、FortiClient EMSのライセンスが必須となる。

FortiClient EMSライセンス
提供形態 サブスクリプション（1年/3年/5年）
価格帯（参考・定価ベース） 25エンドポイント: 年額 約$768（約11-12万円）
500エンドポイント: 年額 約$6,936（約100万円超）
含まれる機能 ZTNA管理、エンドポイント保護（EPP）、脆弱性スキャン、Webフィルタリング、サポート

単なるVPNの代替として見ると高額だが、EDR（Endpoint Detection and Response）や資産管理ツールを兼ねると考えれば、統合的なコスト削減につながる可能性がある。

4.設定に関して

4.1 状態確認と無効化

(1)バージョンの確認

・ダッシュボード > ステータス >システム情報 からバージョンの確認

(2)SSL-VPN機能の無効化

・設定方法として、SSL-VPNをOFFにすれば、無効化できる

(3)SSL-VPN設定の削除

機能の無効化だけでも攻撃されることはないが、不要な設定であるため、削除しておく
a)ファイアウォールポリシーの削除
b)SSL-VPN設定の削除
c)SSL-VPNユーザの削除
d) SSL-VPNユーザグループの削除

(4)設定画面の変化

❶旧画面　v7.2.10の場合

❷7.6.3 以降の設定できない画面

4.2 IPsecへの移行

(1)概要

構成図、設計

(2)設定手順

　★詳細解説、デモ
www.scsk.jp

(3)IPsec IKEv2 over TCP (Port 443)の詳細な設定手順

❶ステップ1：グローバル設定とポートの競合解消
まず、IPsecがTCPポート443を使用できるように、システム全体の設定を変更する。同時に、HTTPS管理アクセスが443を占有しないよう変更する。
・ 管理ポートの変更（推奨）

config system global
    set admin-sport 4443
end

・IPsec用TCPポートの設定

config system settings
    set ike-port 500         # 標準UDP IKE
    set ike-natt-port 4500   # 標準UDP NAT-T
    set ike-tcp-port 443     # ★重要：ここを443に設定
end

解説: ike-tcp-portの設定により、FortiGateは指定されたTCPポートでIKEパケットをリッスンするようになる 。

❷フェーズ1インターフェースの作成
ダイヤルアップ（動的IP）クライアントを受け入れるフェーズ1設定を行う。

config vpn ipsec phase1-interface
    edit "RA_TCP_VPN"
        set type dynamic
        set interface "wan1"       # 公開インターフェース
        set ike-version 2          # ★重要：TCPカプセル化にはIKEv2が必須
        set peertype any
        set net-device disable     # ダイヤルアップ用にインターフェース生成を抑制
        set mode-cfg enable        # クライアントへのIP払い出しを有効化
        set transport tcp          # ★重要：トランスポートモードをTCPに固定
        set encapsulation tcp-encap
        set tcp-port 443           # ポート明示（global設定と一致させる）
        set proposal aes256-sha256 # 強固な暗号化スイート
        set dhgrp 14 21            # Diffie-Hellmanグループ
        set eap enable             # ユーザー認証にEAPを使用
        set eap-identity send-request
        set authusrgrp "VPN_Users" # 認証するユーザーグループ
        set ipv4-start-ip 10.200.1.1
        set ipv4-end-ip 10.200.1.254
        set psksecret <PreSharedKey>
    next
end

技術的洞察: set transport tcp および set encapsulation tcp-encap が、この構成の核となるコマンドである。ike-version 2以外では動作しない点に注意が必要である 。

❸フェーズ2インターフェースの作成
通信トラフィックの暗号化パラメータを定義する。

config vpn ipsec phase2-interface
    edit "RA_TCP_VPN_P2"
        set phase1name "RA_TCP_VPN"
        set proposal aes256-sha256
        set dhgrp 14 21
        set keepalive yes
    next
end

❹ファイアウォールポリシーの設定
VPNインターフェースから内部ネットワークへの通信を許可する。

config firewall policy
    edit 1
        set name "VPN_Access"
        set srcintf "RA_TCP_VPN"
        set dstintf "internal"
        set srcaddr "all"
        set dstaddr "Internal_Subnets"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable  # 必要に応じてNATを有効化
        set groups "VPN_Users"
    next
end

❺FortiClient（エンドポイント）
クライアント側の設定もサーバー側に合わせる必要がある。FortiClient（Windows/Mac）の設定XML例を示す。

XML
<vpn>
    <options>
        <type>ipsec</type>
        <name>Corporate VPN (TCP)</name>
    </options>
    <ipsec>
        <remote_gateway>vpn.company.com</remote_gateway>
        <port>443</port>
        <protocol>ikev2</protocol>
        <auth_method>psk</auth_method>
        <prompt_certificate>0</prompt_certificate>
        <prompt_username>1</prompt_username>
    </ipsec>
</vpn>

GUIで設定する場合、「高度な設定」または「トランスポート」オプションにて「TCP」を選択し、ポートを443に指定する必要がある。また、FortiClientのバージョンは7.0以上、推奨は7.4.xである

(3)FortiConverter Serviceと移行ウィザード

・Fortinetは、この移行を支援するためのツールを提供している。
・SSL VPN to IPsec VPN Migration Wizard: FortiOS 7.6に組み込まれている無料の機能。既存のSSL-VPN設定（ユーザーグループ、認証設定、ポータル設定）を読み取り、同等のIPsec設定（フェーズ1/2、ファイアウォールポリシー）を自動生成する。
・設定は、VPN > SSL VPN to IPsec VPN Migration
・制限: FortiGate側の設定のみを変換する。クライアント（FortiClient）の設定配布は行わないため、EMS等で別途プロファイルを配布する必要がある 。

4.3 セキュリティを高める設定

(1)認証強化

・Client-to-SiteでIPsec-VPNを利用する場合はMFA（メール、証明書、FortiTokenなど）を必ず利用する。または送信元IPアドレス制限により、通信社を限定する。
・二要素認証は、認証情報の突破される場合には有効だろう。ただ、脆弱性を突かれたら意味がない。

(2)要塞化

IPsecにも固有の弱点（IKEスキャンやDoS）が存在するため、それらを補完する厳格な「ハードニング（堅牢化）」設定が不可欠です。
❶Local-In PolicyによるIKE/ESPの着信制限（最重要）
IPsec VPNを有効にすると、デフォルトでは全世界のIPアドレスからのIKE接続試行（UDP 500/4500）を受け付けます。これにより、ikedプロセスが攻撃者のスキャンやDoS攻撃にさらされ、CVE-2025-58413のような潜在的な脆弱性を突かれるリスクが残ります 。

対策： local-in-policy を使用して、接続元IPアドレスを物理的に制限します。これは、パケットがikedプロセスに到達する前に、カーネルレベルでドロップさせる最強の防御策です。

推奨設定例:GeoIPオブジェクトの作成: 日本国内（または業務を行う特定の国）のみを含むアドレスオブジェクトを作成します。
Local-Inポリシーの適用:　許可ルール：GeoIPオブジェクトからの IKE (UDP 500/4500) を accept。拒否ルール：それ以外のすべてのソースからの IKE を deny。

config firewall local-in-policy
    edit 1
        set intf "wan1"
        set srcaddr "Japan"  <-- 許可する国またはIPリスト
        set dstaddr "all"
        set service "IKE"    <-- UDP 500, 4500を含むサービス
        set action accept
        set schedule "always"
    next
    edit 2
        set intf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set service "IKE"
        set action deny      <-- それ以外はプロセスに到達させずに破棄
        set schedule "always"
    next
end

この設定により、攻撃対象領域を地理的に限定し、海外からの無差別な脆弱性スキャンを無効化できます 。

❷IKEおよび暗号化設定のハードニング
IPsecの設定自体も、現代の基準に合わせて強化する必要があります。
・IKEv1の無効化: IKEv1（特にAggressive Mode）は、事前共有鍵（PSK）のハッシュを盗聴されやすく、辞書攻撃に脆弱です。必ず IKEv2 のみを使用する設定を強制してください 。
・強力な暗号化スイートの強制: DES, 3DES, SHA1, MD5などのレガシーアルゴリズムは排除し、AES-256-GCM および SHA-256 以上を使用します。FortiGateのNP（Network Processor）はこれらの処理を高速に行えるため、パフォーマンスへの懸念は不要です 。
・PFS (Perfect Forward Secrecy) の有効化: Diffie-Hellmanグループ（DH Group）は14以上（2048bit以上）または19, 21（ECC）を使用し、万が一鍵が漏洩しても過去の通信が解読されないようにします 。
★実際の画面設定。デフォルトの設定はどうなってる？

❸謎のESPパケット検出の無効化（ログ溢れ対策）
FortiOS 7.2.4以降および7.6系では、IKEネゴシエーションなしで届いたESPパケットに対してログを生成する機能があります。攻撃者がランダムなESPパケットを送り付けることで、ログ領域を圧迫したりCPU負荷を上げたりする攻撃（DoS）が観測されています。

対策: Local-InポリシーでIKEを制限した上で、以下の設定を行い、不正なESPパケットの過剰な検知・ログ記録を抑制します。

config system settings
    set detect-unknown-esp disable
end

これにより、不必要なリソース消費を防ぎ、システムの安定性を高めます 。

4.4 ゼロトラスト（ZTNA）機能

(1)ZTNAアーキテクチャの構成要素

Universal ZTNAは以下の3つのコンポーネントが連携して動作する。
❶FortiGate
従来のファイアウォール機能に加え、「アクセスプロキシ（Access Proxy）」として動作する。外部からの接続要求を受け取り、認証とポスチャ（健全性）チェックを行った上で、内部のアプリケーションサーバーへ代理接続する。ユーザー端末と内部サーバーが直接IP通信することはない 。
❷FortiClient EMS
エンドポイントの管理サーバー。各端末からテレメトリ情報（OSバージョン、パッチ適用状況、AV稼働状況など）を収集し、それに基づいてZero Trust Tag（例：Corporate_PC, High_Risk, Patched）を動的に割り当てる。このタグ情報はリアルタイムでFortiGateに同期される 。
❸FortiClient
エンドポイント上で動作し、EMSへ情報を送信するとともに、ユーザーがアプリケーションへアクセスする際に、デバイス証明書を提示して相互TLS（mTLS）認証を行う 。

(2)ZTNAの動作フロー

a)ユーザーが https://crm.company.com にアクセス。
b)DNSはFortiGateのWAN IP（VIP）を返す。
c)FortiClientがFortiGateに対してTLS接続を開始し、デバイス証明書を提示。
d)FortiGateは証明書の正当性と、EMSから同期されたZTNAタグを確認（例：タグがCompliantであるか）。
e)ポリシーに合致すれば、FortiGateが内部のCRMサーバーへ接続を中継する。
※マイクロセグメンテーション: ユーザーには内部ネットワークのIPアドレスが付与されないため、VPNのようにネットワークスキャンを行ったり、許可されていないサーバーへ横展開（ラテラルムーブメント）したりすることが物理的に不可能となる 。

(3)技術構成詳細：ZTNAの実装

ZTNAの実装には、EMSとFortiGateの連携（Fabric Connector）が必須となる。
❶ステップ1：EMSでのタグ定義
EMS管理画面にて、「Zero Trust Tagging Rules」を作成する。
ルール例：「Windows Defenderが有効」かつ「ドメイン参加済み」の場合 → タグ Low_Risk を付与。
❷ステップ2：FortiGateでのプロキシ設定
CLIを用いたアクセスプロキシの設定例：
・ファブリックコネクタの設定（EMS連携）

config system csf
    set status enable
    set group-name "SecurityFabric"
end
config endpoint-control fctems
    edit "EMS_Server"
        set server "192.168.10.10" # EMSのIP
        set https-port 443
        set certificate "Fortinet_Factory"
    next
end

・ZTNAサーバー（VIP）の設定

config firewall access-proxy
    edit "Web_App_Proxy"
        set vip "Public_VIP_Object"
        set client-cert enable # デバイス証明書の要求
        config api-gateway
            edit 1
                set url-map "/crm"
                set service https
                config realservers
                    edit 1
                        set ip 10.0.1.50
                        set port 443
                    next
                end
            next
        end
    next
end

❸ZTNAルールの設定（ポリシー）

Bash
config firewall proxy-policy
    edit 1
        set name "Allow_CRM_Access"
        set proxy access-proxy
        set access-proxy "Web_App_Proxy"
        set srcintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set ztna-ems-tag "Low_Risk" # EMSタグによる制御
        set action accept
        set schedule "always"
    next
end

この設定により、「Low_Risk」タグを持つ端末のみがCRMへのアクセスを許可される。もし端末がウイルスに感染し、EMSがタグを外せば、即座にアクセスは遮断される 。

4.5 Webモード

・SSL-VPN Webモードは「Agentless VPN」という新しい名称で、継続利用可能
・利用できるのはリバースプロキシサーバと同じで、httpやhttpsの通信のみ（※要確認）

5.IPsecは果たして安全か

5.1 そもそも、なぜIPsecなら安全なのか

❶プロトコルおよび処理レイヤーの違い
IPsec（Internet Protocol Security）は、OSI参照モデルのネットワーク層（レイヤー3）とIKE（UDP500および4500）で動作し、SSL-VPNはアプリケーション層（レイヤー7）で動作します。これは、ファイアウォール上で「Webブラウザ向けのアプリケーション」を動かしているのと同じ状態です。セキュリティ機能を提供するはずのファイアウォールが、最も複雑で攻撃を受けやすいアプリケーション層の処理を引き受けてしまっています。

❷「Webサーバーとして振る舞う」という構造的弱点
・SSL-VPNの場合
Webサーバー（SSL-VPN）は、ログイン画面を表示するために、送られてきたHTTPリクエストの中身（URL、Cookie、User-Agentなどの文字列情報）をすべて読み込み、その意味を解析（パース）しなければなりません。文字列を解釈しようとしてメモリ領域があふれ（バッファオーバーフロー）、その拍子に紛れ込ませた不正コードが実行されてしまいます。これが「認証前」に起きてしまうのが致命的です。
・IPsecの場合
IPsecは「鍵」が合わないパケット、規定のサイズや構造と異なるパケットは、中身を解釈することなく即座に破棄（ドロップ）します。複雑な文字列解析を行わないため、付け入る隙が極めて少ないのです。

参考　NSAとCISAによる発表

■IPsecの推奨
「NSAおよびCISAは、VPN向けの標準化されたセキュリティ要件に対して検証済みの標準化されたインターネット鍵交換/インターネットプロトコルセキュリティ（IKE/IPsec）VPNを推奨します。」

NSA and CISA recommend standardized Internet Key Exchange/Internet Protocol Security
(IKE/IPsec) VPNs that have been validated against standardized security requirements for VPNs.

■SSL/TLS VPNを非推奨
「非標準のVPNソリューション（Secure Sockets Layer/Transport Layer Security（SSL/TLS）VPNと呼ばれる製品群を含む）の選択は避けてください。
これらの製品には、TLS経由でトラフィックをトンネリングするためのカスタムかつ非標準の機能が含まれています。カスタムまたは非標準の機能を使用すると、製品で使用されるTLSパラメータが安全であっても、追加のリスクに晒されることになります。」

Avoid selecting non-standard VPN solutions, including a class of products referred to as Secure Sockets Layer/Transport Layer Security (SSL/TLS) VPNs.
These products include custom, non-standard features to tunnel traffic via TLS.
Using custom or non-standard features creates additional risk exposure, even when the TLS parameters used by the products are secure.

出典：NSA（米国家安全保障局）とCISA（米サイバーセキュリティ・社会基盤安全保障庁)）による発表（2021年9月28日付）
https://media.defense.gov/2021/Sep/28/2002863184/-1/-1/0/csi_selecting-hardening-remote-access-vpns-20210928.pdf


5.2 SSL-VPNの脆弱性の脅威

過去5年間、Fortinet製品に対する攻撃の大部分はSSL-VPN機能を標的としてきました。特筆すべきは、それらの多くが「認証不要（Pre-authentication）」で「リモートコード実行（RCE）」が可能であったという事実です。これは、攻撃者がIDやパスワードを持たずとも、外部からパケットを送信するだけでファイアウォールの制御権（root権限）を奪取できることを意味します。

■代表的な致命的脆弱性
・CVE-2022-42475 (CVSS 9.8 - Critical)
sslvpndにおけるヒープベースのバッファオーバーフロー脆弱性です。特細工されたHTTPリクエストを処理する際のメモリ管理不備を悪用し、認証なしで任意のコード実行が可能でした。この脆弱性は「ゼロデイ」として実際に悪用されました 。   

・CVE-2023-27997 (CVSS 9.8 - Critical)
通称「XORtigate」と呼ばれるこの脆弱性も、SSL-VPNのWebポータル処理におけるヒープオーバーフローでした。MFA（多要素認証）が有効であっても、MFAの処理が行われる「前」にメモリ破壊が発生するため、防御不可能でした。この脆弱性は、ランサムウェアグループによる初期侵入経路として広く悪用されました 。   

・CVE-2018-13379 (CVSS 9.8 - Critical)
パストラバーサル（ディレクトリトラバーサル）の脆弱性であり、認証なしでシステムファイル（sslvpn_websessionなど）を読み取ることが可能でした。これにより、ログイン中のユーザーの平文パスワードが流出する事態となりました 。

5.3 FortiGateにおけるこれまでのIPsecの脆弱性

一方、IPsec VPN（iked）に関連する脆弱性は、その性質と影響度がSSL-VPNとは大きく異なります。IPsecなら絶対に安全とは言えませんが、攻撃の難易度と前提条件がより厳しい傾向にあります。

■IPsec関連の主な脆弱性
・CVE-2024-46669 (CVSS 3.5 - Low/Medium)
IKEサービスにおける整数オーバーフローの脆弱性です。これによりikedプロセスがクラッシュし、DoS（サービス拒否）状態になる可能性があります。しかし、この脆弱性を悪用するには認証済みの攻撃者である必要があります。つまり、攻撃者はすでにVPNの認証情報を盗み出しているか、内部犯である必要があり、外部からの無差別攻撃には利用できません 。   

・CVE-2023-46715 (CVSS 4.7 - Medium)
IPsec VPNにおけるオリジン検証エラーです。認証済みのユーザーが、他のユーザーのIPアドレスになりすましてパケットを送信できる可能性があります。これも認証済みユーザーに限定された攻撃であり、システム全体の掌握（RCE）には直結しません 。   

・CVE-2025-58413 (CVSS 7.5 - High)
比較的最近報告されたスタックベースのバッファオーバーフロー脆弱性であり、認証なしでRCEが可能となるリスクがあります。これはIPsecの実装においてもメモリ破壊系の脆弱性が起こり得ることを示していますが、SSL-VPNの頻発する脆弱性と比較すればレアケースであり、また攻撃にはバイナリパケットの精巧な操作が必要となるため、HTTPリクエストを悪用するものより技術的ハードルが高いとされます 。

・以下は、Fortinet社のPSIRTのサイト。脆弱性情報が確認できる。
https://www.fortiguard.com/psirt
【IPsecで検索】
CriticalとHighを探すと2件しかない。そのうち、画面の下側のはFGFMの内容なので、実際にはHighの1件しかない。また、そのHigh内容も、DDoSの影響などであり、今回のSSL-VPNの任意のコードが実行できるものはない。

【sslvpnで検索】
CriticalとHighを探すと11件。その中で、Criticalが4件で、先に述べた重大な脆弱性のCVE-2023-27997などもある。

比較項目 SSL-VPN IPsec
悪用条件 認証不要で攻撃できた例が多数有り IKEフェーズ1で厳密なパラメータ交換を行うので、事前共有鍵などがないと攻撃はほぼ不可能
影響度 完全なシステム掌握
SSL-VPNの侵害は即座に組織全体の脅威となる		 サービス停止 (DoS) やなりすまし
攻撃手法 HTTPリクエストの操作 IKEパケットの操作
補足 HTTP/HTTPSプロトコルを使用する、これはテキストベースであり、攻撃者はWebブラウザやBurp Suite、curlなどの一般的なツールを使って簡単に異常なデータを送り込むことができ、Fuzzing（検査ツールによる総当たり攻撃）も容易 IKEはUDP上のバイナリプロトコルであり、パケット構造や状態遷移が厳格。攻撃するのは非常に困難

つまり、IPsecへの移行はセキュリティリスクを「管理可能なレベル（DoSや認証済み攻撃）」へと低減させる効果があります。

■注意点
ただし、Cisco ASAシリーズのソフトウェアにおけるVPN接続の「IKEv1」「同v2」処理に存在する脆弱性があったので、IPsecは脆弱性を突かれることが無いとは言えない。
https://www.security-next.com/066862

5.4 IPsecで代用できるのか

Q.ホテルなどのWifiではIPsecが使えないのではなかったか

従来のIPsec、TCPではなくESPをを使用するため、接続できないことがよくありました。
そこで、そこで、NAT TraversalおよびUDP Encapsulation of IPsec Packets（UDP4500）を使い、ESPではなくUDPにして通過できるようにしました。
ですが、少し前から、 多くのホテルや公衆Wi-Fiのゲストネットワークでは、Firewallが導入され、Web閲覧（TCP 80/443）以外の通信を遮断する設定が増えています。そこで、FortiOSとFortiClientに実装されている「IPsec over TCP」機能です。 FortiOS 7.0以降およびFortiClient 7.0以降では、IKEv2パケットおよびESPペイロードをTCPヘッダーで包み込み、ポート443（または任意のTCPポート）で通信させる機能が実装されています。

6.メーカー対応

6.1 いつまでの対応すべきかについて

(1)ソフトウェアのライフサイクル
フェーズ 名称 意味 内容 期間の目安
1 GA (General Availability) 一般利用可能 リリース開始。フルサポート状態 約36ヶ月（3年）
↓
2 EOES(End of Engineering Support) エンジニアリングサポート（開発修正）の終了 新機能や通常のバグ修正が終了。脆弱性パッチのみ提供される さらに約18ヶ月（1.5年）
↓
3 EOS(End of Support) 全サポートの完全終了（EOL） 使用停止推奨 ―
(2)EOESとEOSの主な違い
項目 EOES (End of Engineering Support)
エンジニアリングサポート終了 		EOS (End of Support)
サポート終了
主な意味 開発部門による開発・修正が終了する。
ただし、致命的な問題のみ例外対応される。 		メーカーからの全ての支援が停止する。
使用し続けることは極めて危険。
バグ修正 △ **致命的な不具合・重大な脆弱性のみ**修正 × 一切修正されない
シグネチャ更新**
(AV/IPS等) 		○ 継続して提供される × **配信停止
技術問合せ ○ 可能（ただし調査は既知事例ベース） × 受付不可
目安時期 ソフトウェア(OS)のリリースから約36ヶ月後 ハードウェアの販売終了から5年後
ソフトウェアのリリースから約54ヶ月後

一言で言うと
・EOES:新機能や通常のバグ修正は止まるが、セキュリティパッチ（重大なもの）は出るため、移行準備期間として使える。
・EOS:セキュリティパッチもシグネチャも完全に止まるため、この日までに更改必須。

(3)メーカ―の見解

以下、メーカの資料

6.2 自動アップデート

(1)概要

・FortiOS 7.6.4 および FortiOS 7.4.8 より、「機器のサポート契約が無効」もしくは「OSがEnd of Support（EOS）を迎えている」場合に、OSが最新のパッチバージョンに強制的に自動アップグレードされる機能が追加された。
・ここでの「パッチバージョン」とは、「3桁目の数字のみが変わるアップデート（例：7.4.8 → 7.4.9）」**を指します。7.4.8 が勝手に 7.6.x や 7.8.x（架空のバージョン）などの別メジャー/マイナーバージョンへアップグレードされることは、この機能の仕様上はありません。
・目的は？

Q.目的は？

→EOSの状態は変わらないが、そのバージョンにおける既知の脆弱性は塞がれた状態になります。

・アップデートは「完全ランダム」ではなく、機器で指定した開始～終了時間の枠内で、アクセス集中を防ぐために分散（ランダム）実行される。

(2)ケーススタディ

✅ ケース1：EOS（サポート終了）を迎えた場合
2026/5/11にEOS → 5/14頃に7.4.9（最新パッチ）へ強制Update

✅ ケース2：ライセンス（サポート契約）が切れた場合
2026/2/10にライセンス切れ → 2/13頃に7.4.9へ強制Update

✅ ケース3：古いバージョン（機能未搭載）の場合
バージョン 7.2.x（古い） → 強制Update無し

※重要なポイント:「7.4.3 → 7.4.9」 という動きになり、「7.6.x」のような別系統へ勝手に飛躍しません。

(3)調整コマンド
config system fortiguard
    # (1) 自動アップグレード機能の有効化（強制される場合は enable になっているはずです）
    set auto-firmware-upgrade enable

    # (2) 実行する曜日（例: 日曜日）
    set auto-firmware-upgrade-day sunday

    # (3) 実行開始・終了時間（例: 深夜2時～5時）
    set auto-firmware-upgrade-start-hour 2
    set auto-firmware-upgrade-end-hour 5

    # (4) 【重要】リリース後の遅延日数（例: 3日待つ）
    # これを設定しないと、リリース直後の深夜に走る可能性があります
    set auto-firmware-upgrade-delay 3
end
(4)強制を止める方法はないのか

CLIにて機能を無効化（disable）するコマンド自体は存在します。
以下のコマンドが入るか（設定が有効か）を確認してみてください。★コマンドが入る？

config system fortiguard
    set auto-firmware-upgrade disable
end

7.UTMのセキュリティ設定

また、最近、ランサムウエアの被害が増えていますが、内部のラテラルムーブメントであったり、C＆Cサーバへの通信防御のために、FortiGateの設定を見直すことは非常に有効です。具体的には、中外への通信の強化（FW、IPS、URLフィルタ、アプリケーションコントロールなど）、ログの設定とアラートをしっかりするだけでも、ものすごく効果（防げる、または気づける）があります。攻撃を気づければ、被害を最小限にするためのアクションをうつことができます。そんな話も、イベントの中でお伝えしたいと思います。