FortiGate UTM 機能の仕組みと IPS 誤検知のリスクと対処

はじめに

FortiGate は、ファイアウォール機能に加えて、アンチウイルス・Web フィルタリング・IPS（侵入防御）など複数のセキュリティ機能を 1 台のアプライアンスに統合した、UTM（Unified Threat Management: 統合脅威管理） 製品です。

多層的な防御機能を備える FortiGate ですが、その仕組みを正しく理解していないと、「通信が想定外に止まる」「正常な通信を攻撃と誤検知する」といったトラブルへの対処が難しくなります。本記事では、FortiGate の防御の中心となる仕組みから、現場でよく直面するトラブルシューティング（誤検知対策）までを体系的に整理します。検証は FortiOS 7.4 / 7.6 系 を前提にしています。

UTM と NGFW の違い

FortiGate を扱うと、UTM（Unified Threat Management） と NGFW（Next Generation Firewall） という 2 つの呼称に出会います。本記事のタイトルも「UTM 機能」としていますが、現在の Fortinet の製品ページでは NGFW という用語が中心に使われています。両者の違いを整理しておきます。

FortiGate は両方の側面を備える製品 で、機能セットの呼び方として UTM と NGFW のどちらも使われます。本記事では従来の呼称である「UTM」を軸に解説しますが、内容は NGFW としての利用にも当てはまります。

参考: Fortinet / FortiGate Next Generation Firewall
“FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard Labs.”
（FortiGate NGFW は、専用設計のセキュリティプロセッサと FortiGuard Labs の脅威インテリジェンスサービスを活用します）
https://www.fortinet.com/products/next-generation-firewall

UTM の枠を越える現代の FortiGate

近年の FortiOS では、UTM / NGFW の枠を越えた機能群も標準的に提供されています。本記事の対象範囲外ですが、選定・運用のうえで意識しておきたい関連機能として以下が挙げられます。

• SD-WAN: 複数の WAN 回線を束ね、アプリケーションごとに最適な経路を選択する機能
• ZTNA（Zero Trust Network Access）: ユーザーやデバイスごとにアプリ単位でアクセス制御する仕組み
• SASE（Secure Access Service Edge）連携: FortiSASE などのクラウドサービスとの統合
• DLP（Data Loss Prevention）: 機密データの外部漏洩を防ぐ機能
• FortiAI 連携: AI による脅威分析や運用支援

これらは UTM（脅威防御）の延長線上にある機能群で、現代のセキュリティ要件に応じて段階的に活用が広がっています。

FortiGate のステートフルインスペクション

FortiGate のファイアウォール機能の主な特徴は、ステートフルインスペクション（状態検知型） という仕組みを採用している点です。これは、パケットの送信元 / 宛先だけでなく、通信の文脈（ステート） を理解して動的にポートを開閉する技術です。

従来のパケットフィルタリングとの違い

セッションテーブルによる戻り通信の自動許可

FortiGate は、許可された通信が発生すると、メモリ上に セッションテーブル という管理情報を作成します。

行きの通信

PC から Web サーバへのアクセスが発生し、ファイアウォールポリシーで許可されると、セッションテーブルに「PC A と サーバ B が通信中」と記録されます。

戻りの通信

Web サーバから PC への応答が戻ってくると、FortiGate はポリシーを再評価する前にセッションテーブルを参照し、対応する通信であれば許可されます。

この仕組みにより、管理者は「行き（LAN → WAN）」のポリシーだけを定義すればよく、設定の手間と漏れのリスクを抑えられます。

セッションテーブルの確認コマンド

# ▼ 全体のセッション統計（合計数・TCP / UDP の内訳）
FortiGate # diagnose sys session stat

# ▼ 特定の送信元 IP に絞って確認
FortiGate # diagnose sys session filter src 192.168.1.10
FortiGate # diagnose sys session list

# ▼ フィルタの解除
FortiGate # diagnose sys session filter clear

セッションテーブルにはエントリ数の上限があり、エントリー機種では数十万、上位機種では数千万のオーダーになります。同時接続数が上限に達すると新規セッションが破棄される ため、大規模環境では機種選定時にセッション処理性能を確認することをおすすめします。

参考: Fortinet Document Library / Stateful Firewall Inspection Overview（FortiGate）
“Stateful inspection tracks the state of network connections traversing the firewall and uses this information to determine whether to allow or block traffic.”
（ステートフルインスペクションはファイアウォールを通過するネットワーク接続の状態を追跡し、その情報をもとに通信の許可 / 遮断を判定します）
https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/

ネットワーク層の防御（IPS / DoS ポリシー）

ファイアウォールのポート制御だけでは防ぎきれない、OS やミドルウェアの脆弱性を突く攻撃や、サービス停止を狙った大量アクセス攻撃を防ぐための機能群です。

IDS / IPS（侵入検知・防御）

FortiGate の IPS（Intrusion Prevention System）は、通過するパケットの中身を検査し、既知の攻撃パターンと一致した場合に通信を遮断します。

シグネチャマッチングの仕組み

FortiGate は、FortiGuard Labs から配信される シグネチャ（攻撃パターンの特徴データ） を保持しており、22,000 を超える IPS シグネチャ が含まれます。パケットのデータ列がシグネチャと一致するかを照合し、Apache Struts の脆弱性を突くコードや SQL インジェクションといった攻撃を識別します。シグネチャは FortiGuard Labs から定期的に更新されます。

IPS 誤検知（フォールスポジティブ）への対処

IPS を運用するうえで現場でよく直面するのが、正常な通信を攻撃と判定する 誤検知（フォールスポジティブ） です。FortiGate では特に、arp_spoofing のログが大量に出力されるケース が見られます。

よくある誤検知のパターン

L2 ループ検知パケット

スイッチがループ検知用の特殊フレームを送出した際、FortiGate が「ARP テーブルを不正に書き換える試み」と判定するケース

脆弱性スキャン

社内の資産管理ツールやセキュリティ診断ツールがネットワークスキャンを行った際に攻撃と判定されるケース

冗長化プロトコル

VRRP や HSRP のパケットが攻撃と判定されるケース

対処手順 1: パケットキャプチャでの確認

除外設定を追加する前に、まず diagnose sniffer packet コマンドでパケットを確認し、送信元 MAC アドレスや内容から正規機器（社内のスイッチやスキャナ）の通信であることを確認することをおすすめします。

# ▼ ARP パケットをキャプチャ（インターフェース all、verbose 4 = ヘッダ詳細表示）
FortiGate # diagnose sniffer packet any "arp" 4 0 a

# ▼ 特定インターフェースに絞る場合
FortiGate # diagnose sniffer packet port1 "arp" 4 0 a

# ▼ 特定 IP からの通信のみ
FortiGate # diagnose sniffer packet any "host 192.168.1.10 and arp" 4 0 a

diagnose sniffer packet の末尾の引数 a は絶対時刻を表示するオプションです。Ctrl+C で停止 します。

対処手順 2: IPS シグネチャの除外設定

正規の通信であることが確認できたら、該当シグネチャを除外（Exempt）します。GUI では IPS センサー設定で対象シグネチャを右クリックし「除外」を追加します。CLI でも以下のように設定できます。

config ips sensor
    edit "default"
        config entries
            edit 1
                set rule 11700    # ← 該当シグネチャ ID
                config exempt-ip
                    edit 1
                        set src-ip 192.168.1.10 255.255.255.255
                    next
                end
            next
        end
    next
end

送信元 IP 単位で除外を絞る運用（特定機器からの通信のみシグネチャを無視する）にすると、セキュリティを過度に下げずに誤検知を抑えられます。

参考: Fortinet Document Library / IPS sensor exemptions
“You can exempt specific source or destination IPs from being scanned by an IPS signature.”
（IPS シグネチャによる検査対象から、特定の送信元 / 宛先 IP を除外することが可能です）
https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/

DoS / DDoS 攻撃対策

DoS（Denial of Service）攻撃は、サーバが処理しきれない量のリクエストを送りつけ、サービス停止を狙う攻撃です。FortiGate には通常のファイアウォールポリシーとは別に、DoS ポリシー（IPv4 DoS Policy） という専用の防御設定があります。

SYN フラッド攻撃への防御

接続開始の合図（SYN パケット）だけを大量に送りつけ、サーバの接続待ちリソースを枯渇させる攻撃です。「1 秒間に N 回以上の SYN パケットを受信した場合に遮断」といった 閾値（スレッショルド） を設定し、異常なトラフィックのみをドロップします（アノマリー検知）。

DoS ポリシーの設定例（CLI）

config firewall DoS-policy
    edit 1
        set name "Anti-SYN-Flood"
        set interface "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        config anomaly
            edit "tcp_syn_flood"
                set status enable
                set log enable
                set action block
                set threshold 2000    # ← 1 秒あたり 2000 個を超えた SYN を遮断
            next
        end
    next
end

閾値を厳しくしすぎると正常な業務通信もドロップされる可能性があるため、運用環境のベースライン値を計測したうえで設定することをおすすめします。

コンテンツ層の防御（Web / メール / アプリ）

ステートフルインスペクションや IPS が「パケットの動き」を監視するのに対し、コンテンツ層の防御機能は通信の中身であるファイルやアプリケーションの動作を直接検査します。

アンチウイルスとサンドボックス

マルウェア（ウイルス・ランサムウェアなど）から端末を守るための、2 段構えの防御機能です。

アンチウイルス（既知の脅威）

従来のパターンマッチング方式です。FortiGate は、既知のウイルスの特徴を登録した大規模なシグネチャデータベースを保持しています。通過するファイルをデータベースと照合し、一致したらブロックします。処理は高速ですが、新種（ゼロデイ）のマルウェアは検知できない という制約があります。

サンドボックス（未知の脅威）

シグネチャに一致しない不審なファイルを、FortiSandbox（オプション製品 / クラウドサービス）に転送し、隔離された仮想環境で実行します。「ファイルを暗号化する動作」「外部の C&C サーバと通信する動作」といった振る舞いを観察し、有害かどうかを判定します。

未知の脅威も検知できますが、解析に時間がかかります（一般的に数十秒〜数分）。利用には FortiSandbox 本体または FortiSandbox Cloud のライセンス が前提です。

Web フィルタリング

業務に関係のないサイトや危険なサイトへのアクセスを抑制する機能です。URL そのものではなく、サイトの カテゴリ で判定するのが特徴です。

カテゴリブロックの仕組み

FortiGate は、FortiGuard Labs が提供する大規模な URL カテゴリデータベース（約 90 カテゴリ）を参照します。たとえば、社員が http://example-casino.com にアクセスを試みると、FortiGate は URL のカテゴリを照会し、「ギャンブル」カテゴリと判定された場合、社内ポリシーに応じて遮断します。

主なブロック対象カテゴリ: アダルト、ギャンブル、違法薬物、マルウェア配布サイト、フィッシングサイトなど。

アプリケーションコントロール

従来のファイアウォールでは制御が難しいアプリケーションの利用を制限する機能です。

ポート番号で制御できない理由

従来は「Web は ポート 80」「メールは ポート 25」と、サービスとポート番号が対応していました。一方、現代のアプリケーション（SNS・クラウドストレージ・P2P など）の多くは Web と同じ ポート 80 / 443 を利用したり、動的にポートを変えたりするため、ポート番号だけでは識別できません。

FortiGate は、ポート番号ではなくパケットの中身（ヘッダやペイロードの構造）を解析 し、6,000 を超えるアプリケーションシグネチャ をもとに通信を識別します。これにより、「業務時間中の SNS 利用の制限」「情報漏洩のリスクがあるツール（Tor など）の遮断」といった細かい制御が可能になります。

現代に欠かせない SSL インスペクション

ここまで整理してきた IPS・アンチウイルス・Web フィルタリングといった防御機能を実効的に動作させるうえで重要なのが、SSL インスペクション（Deep Inspection） です。

現代のトラフィックは大半が暗号化されている

Google の透明性レポートによると、Chrome ブラウザでの HTTPS（暗号化）通信比率は 95% 以上 に達しています。プライバシー保護の観点では望ましい状況ですが、セキュリティ機器にとっては「中身が見えない暗号化通信」が増えたことを意味します。

SSL インスペクション無効時の挙動

FortiGate であっても、暗号化された通信の中身をそのまま検査することはできません。SSL インスペクションが無効の場合、暗号化されたウイルスや不正な通信があっても、FortiGate は中身を見ずに通過させる動作になります。IPS / アンチウイルス / Web フィルタなどの機能は、ライセンスの価格に関わらず、暗号化された通信の中身に対しては効果が大きく低下します。

導入時のハードル

SSL インスペクションを有効にすると、PC のブラウザで「この接続はプライベートではありません」というセキュリティ警告（証明書エラー）が表示されます。これを回避するには、PC 側に FortiGate の証明書をインストールする などの設定が必要です。詳しい設定手順については、関連記事『FortiGate SSL インスペクション（Deep Inspection）の設定手順』で解説しています。

参考: Google Transparency Report / HTTPS encryption on the web
“HTTPS encrypts nearly all information sent between a client and a web service.”
（HTTPS はクライアントと Web サービス間で送受信される情報のほぼすべてを暗号化します）
https://transparencyreport.google.com/https/overview

設計時に押さえたい制約事項

FortiGate の各機能には、設計段階で把握しておきたい制約や前提条件があります。後からの構成変更やパフォーマンス問題を抑えるうえで、導入前に確認しておきたいポイントを整理します。

SSL インスペクションに関する制約

証明書ピンニング（Certificate Pinning）アプリには適用できない

銀行アプリや一部の SaaS・決済アプリなどは、アプリ内に正規の証明書情報を埋め込んでおり、FortiGate が提示する独自証明書を拒否します。これらのアプリでは SSL インスペクションを除外設定する必要があります。

証明書配布の運用負荷

SSL Deep Inspection を有効にする場合、組織内の全 PC・スマートフォンに FortiGate の CA 証明書を配布する仕組み（Active Directory のグループポリシー、MDM など）が前提になります。

TLS 1.3 への対応

FortiOS 7.x 系では TLS 1.3 もサポートされていますが、TLS 1.3 では SNI 以降が暗号化されるため、ホスト名ベースの除外設定の挙動が TLS 1.2 とは異なる点に注意が必要です。

IPS / セキュリティ機能のパフォーマンスへの影響

シグネチャ数増加によるスループット低下

IPS シグネチャを多く有効化すると、検査負荷が高まりスループットが低下します。SPU（Security Processing Unit）搭載モデル ではハードウェアアクセラレーションで一定程度緩和されますが、すべての処理が SPU で吸収されるわけではありません。

データシートの値は理想条件

データシートに記載されているスループット値は、機能ごとの最大値です。IPS ＋ アンチウイルス ＋ Web フィルタ ＋ SSL インスペクションを同時有効化すると、実効スループットはデータシート値を大きく下回ることが一般的です。

セッションテーブルの上限

同時接続数の上限

機種ごとにセッションテーブルの上限が定められており、上限到達時には新規セッションが破棄されます。diagnose sys session stat で現在のエントリ数を定期的に確認することをおすすめします。

NAT セッションは消費が大きい

NAT を併用する環境では、1 通信あたり複数のセッションエントリを消費するケースがあります。

DoS ポリシーの誤判定リスク

閾値設定が厳しすぎると正常通信もドロップ

SYN フラッド対策の閾値を低く設定すると、正常な業務トラフィックの瞬間的な増加でドロップが発生する可能性があります。導入前に ベースラインの計測 を行い、平常時の数倍程度に余裕を持たせた閾値設定をおすすめします。

DoS ポリシーは通常のファイアウォールポリシーより前段で評価される

通常ポリシーで許可されている通信でも、DoS ポリシーの閾値を超えると遮断されます。

サンドボックス連携の前提

FortiGate 単体では未知の脅威解析は限定的

高度な振る舞い解析には FortiSandbox（オンプレ）または FortiSandbox Cloud のライセンスが前提になります。

解析にはタイムラグがある

サンドボックス解析には数十秒〜数分を要するため、リアルタイムでのブロックではなく、解析完了後の対応（後続通信のブロック・エンドポイントへの通知）になります。

トラブルシューティングの基本コマンド

FortiGate の UTM 機能で想定外の挙動に直面した場合に役立つ、CLI ベースの切り分けコマンドを整理します。症状（通信が止まる / 誤検知が発生 / パフォーマンスが低下する）に応じて使い分け ます。

① セッション状態の確認

通信が想定どおりに通らない場合、まずセッションテーブルにエントリが作成されているかを確認します。

# ▼ 全体のセッション統計
FortiGate # diagnose sys session stat

# ▼ 特定の送信元 IP に絞って確認
FortiGate # diagnose sys session filter src 192.168.1.10
FortiGate # diagnose sys session list

# ▼ フィルタの解除
FortiGate # diagnose sys session filter clear

確認ポイント: セッションエントリが作成されているか（作成されていなければポリシーで遮断されている可能性）/ state が est（established）になっているか / policy_id が想定どおりのポリシーを参照しているか

② パケットキャプチャによる切り分け

FortiGate を通過するパケットを直接確認します。許可 / 遮断の境界を切り分けるうえで有効です。

# ▼ HTTPS 通信のみを全インターフェースでキャプチャ
FortiGate # diagnose sniffer packet any "tcp port 443" 4 0 a

# ▼ 特定ホスト宛の通信のみ
FortiGate # diagnose sniffer packet any "host 8.8.8.8" 4 0 a

verbose の値の目安: 1（ヘッダのみ）、4（ヘッダ詳細）、6（フルペイロード）。ペイロードを大量に出力するとコンソールが重くなるため、必要に応じて使い分けます。

③ ファイアウォールポリシーのデバッグ

「どのポリシーで通信が許可 / 遮断されているか」をリアルタイムで追跡します。

# ▼ パケットフローのデバッグを有効化
FortiGate # diagnose debug flow filter addr 192.168.1.10
FortiGate # diagnose debug flow show function-name enable
FortiGate # diagnose debug flow trace start 100    # ← 100 パケット分を追跡
FortiGate # diagnose debug enable

# ▼ デバッグ停止
FortiGate # diagnose debug flow trace stop
FortiGate # diagnose debug disable
FortiGate # diagnose debug reset

確認ポイント: Allowed by Policy-X → 想定どおりのポリシーで許可 / Denied by forward policy check → ポリシーで遮断 / iprope_in_check() check failed on policy 0, drop → デフォルト動作で破棄

④ IPS / UTM ログの確認

IPS や Web フィルタ、アンチウイルスでブロックされた通信は UTM ログで確認できます。

# ▼ UTM カテゴリのログを表示
FortiGate # execute log filter category 1
FortiGate # execute log display

GUI 側では「Log & Report > Security Events」または「Forward Traffic」から、誤検知の発生状況を確認できます。

⑤ パフォーマンスの確認

スループット低下や応答遅延が発生した場合、CPU / メモリの利用状況を確認します。

# ▼ システム全体のリソース使用状況
FortiGate # get system performance status

# ▼ プロセスごとの CPU 使用率（5 秒間隔、30 行表示）
FortiGate # diagnose sys top 5 30

# ▼ HA / クラスタ構成の場合
FortiGate # diagnose sys ha status

確認ポイント: ipsengine の CPU 使用率が高い → IPS 検査負荷 / scanunit の CPU 使用率が高い → アンチウイルス / Web フィルタの負荷 / メモリ利用率が 80% を超える → Conserve Mode（メモリ保護モード）への移行に注意

共通の切り分け観点

UTM 機能で問題が発生した場合は、以下の順で切り分けることが効率的です。

1. 物理 / リンクアップ: インターフェース状態（get system interface physical）
2. セッション形成: セッションテーブルにエントリがあるか
3. ポリシー判定: パケットフローデバッグでどのポリシーがマッチしているか
4. UTM プロファイル: IPS / アンチウイルス / Web フィルタのログでブロック理由を確認
5. SSL インスペクション: HTTPS 通信のみ問題が出る場合、Deep Inspection の証明書配布や除外設定を確認
6. パフォーマンス: CPU / メモリ / セッション数の上限到達がないか

まとめ

本記事では、FortiGate の UTM 機能の仕組みと、運用上のポイントについて整理しました。

• ステートフルインスペクションは通信の文脈を判定し、戻り通信を自動的に許可することで設定の手間とミスを抑える仕組み
• IPS は脆弱性攻撃を防ぐ機能だが、ARP スプーフィングなどの誤検知が発生するため、パケットキャプチャでの確認と除外設定によるチューニングが運用のポイントになる
• DoS ポリシーは SYN フラッドなどの大量アクセス攻撃を閾値で遮断する機能で、業務通信に影響しない値に調整する。
• コンテンツ層の防御（アンチウイルス・Web フィルタ・アプリケーションコントロール）は、ファイルや通信の中身を検査する機能で、未知の脅威にはサンドボックス連携が有効
• SSL インスペクションは、IPS / アンチウイルス / Web フィルタなどを実効的に動作させる前提となる機能で、現代のインターネット環境ではほぼ必須の構成
• UTM と NGFW は呼称の違いで、FortiGate はその両面を備えており、SD-WAN / ZTNA / DLP など UTM の枠を越えた機能群も標準的に提供される。
• 設計時は SSL インスペクションの証明書配布・スループット低下・セッション上限など、機能有効化に伴う制約を事前に確認しておくことで手戻りを防げる。

以上、最後までお読みいただきありがとうございました。