FortiGate Firewall Policy 設計の手順｜IP レピュテーション活用

はじめに

Firewall Policy は FortiGate の中心的な機能ですが、設定の自由度が高いぶん、「とりあえず通す」設計になりやすい部分でもあります。送信元・宛先・サービスを広く許可したポリシーや、インターフェースに ANY を指定したポリシーは、設定を簡潔にする一方で、意図しない通信を通し、攻撃面を広げる原因になります。

本記事では、FortiGate の Firewall Policy を最小権限で設計し、リスクの高い通信を絞り込む手順をまとめます。FortiGate 自身宛の通信を制御する Local-in-Policy は関連記事『FortiGate 管理アクセス制限の手順』で扱っており、本記事は FortiGate を通過する通信の設計に絞ります。設定全体の優先度は『FortiGate ハードニングの優先度と確認手順』で扱っています。

Firewall Policy の堅牢化は、必要な通信のみを具体的に許可し、リスクの高い通信先をレピュテーションやジオブロッキングで絞り、使われていないポリシーを整理する、という流れで整理できます。ポリシーの変更は既存セッションの再評価を伴うため、影響を見込んで進めます。以降では各観点を順に扱います。

Firewall Policy 設計の基本

FortiGate のポリシーは上から順に評価され、最初に一致したルールが適用されます。どのルールにも一致しない通信は破棄されます（暗黙の deny）この前提のうえで、必要な通信だけを具体的に許可する設計が基本になります。

すべて許可（allow all）を避ける

送信元・宛先・サービスをすべて許可するポリシーは、設定を簡潔にする一方で、不要な通信まで通してしまいます。基本方針は「既定で拒否し、必要なものだけを許可する」ことです。広い許可ポリシーを置く場合でも、その手前に、ブロックすべき通信（特定の国・IP・サービス）の deny ポリシーを配置します。

ANY インターフェースを使わない

通信を許可するポリシーでは、送信元・宛先のインターフェースに ANY を使わず、具体的なインターフェースを指定します。ANY を使うと、想定していない経路の通信まで対象に含まれる可能性があるためです。

参考: Fortinet「Best practices for firewall policy configuration」
“Avoid using ‘any’ interface as either the source or the destination interface”
（送信元・宛先のいずれのインターフェースにも any を使うことは避ける）
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Best-practices-for-firewall-policy-configuration/ta-p/193255

送信元・宛先・サービスを具体的に指定する

インターフェースに加えて、送信元・宛先のアドレスとサービスも、必要な範囲に絞って指定します。アドレスは all ではなく具体的なサブネットやアドレスオブジェクトを、サービスは ALL ではなく必要なポートのみを指定します。

config firewall policy
    edit 1
        set name "lan-to-web"
        set srcintf "lan"
        set dstintf "wan1"
        set srcaddr "LAN_SUBNET"
        set dstaddr "WEB_SERVERS"
        set action accept
        set schedule "always"
        set service "HTTPS"
        set logtraffic all
    next
end

この粒度で書くと、想定外の通信が自然に除外され、ログの可読性も高まります。logtraffic all を有効にしておくと、ポリシーの実際のヒット状況を後から精査しやすくなります（精査の進め方は後述します）。

多数の VLAN やインターフェースを扱う場合は、ゾーンでインターフェースをグループ化し、ゾーン内通信を遮断（intrazone deny）する設計も、ポリシーの重複を抑えつつ境界を保つうえで有効です。

確認: show firewall policy、個別ポリシーは get firewall policy <id>

ジオブロッキングと Internet Service の活用

通信先を絞り込む手段として、地域単位のジオブロッキングと、FortiGuard の Internet Service データベース（ISDB）を使ったサービス単位の制御があります。

ジオブロッキング

グローバルな接続を必要としないサービスでは、特定の地域からのアクセスを制限することで、攻撃対象領域を縮小できます。地域は地理アドレスオブジェクトとして定義し、deny ポリシーで使用します。

config firewall address
    edit "Blocked_Countries"
        set type geography
        set country "CN"
    next
end
config firewall policy
    edit 10
        set name "block-countries"
        set srcintf "wan1"
        set dstintf "internal"
        set srcaddr "Blocked_Countries"
        set dstaddr "all"
        set action deny
        set schedule "always"
        set service "ALL"
    next
end

設計の基本で触れたとおり、deny ポリシーは広い許可ポリシーより上位に配置します。公開サービスを持たず、特定地域との通信が不要な環境ほど、ジオブロッキングの効果が見込めます。

確認: show firewall policy

Internet Service（ISDB）によるサービス単位の制御

ISDB は、IP アドレス範囲・所有者・ポート番号・IP の信頼度を統合した、FortiGuard 由来の公開 IP データベースです。地理情報やレピュテーション、人気度なども含み、ポリシーの送信元・宛先オブジェクトとして使えます。たとえば、既知の悪意ある送信元カテゴリを deny ポリシーで遮断する用途に使えます。

config firewall policy
    edit 11
        set name "deny-malicious-src"
        set srcintf "wan1"
        set dstintf "internal"
        set srcaddr "all"
        set internet-service-src enable
        set internet-service-src-name "Malicious-Malicious.Server"
        set action deny
        set schedule "always"
        set logtraffic all
    next
end

利用できる Internet Service の名称は環境やバージョンで異なるため、GUI・CLI で選択可能なエントリを確認して指定します。なお、スポーク 2 で触れた FortiGate 自身宛の既定 Local-in-Policy も、同様に ISDB の悪意ある送信元カテゴリを使っています。

確認: show firewall policy、ISDB は GUI の「ポリシーとオブジェクト」のインターネットサービスで確認します。

IP レピュテーション（ISDB）によるリスクの高い通信先の制御

ISDB には IP のレピュテーション（信頼度）が 5 段階で付与されており、これをポリシーのフィルター条件に使えます。ポリシーに最低レピュテーションレベルを設定すると、送信元または宛先 IP のレピュテーションがそのレベル以上であれば通信を許可し、未満であれば破棄します。リスクの高いカテゴリ（マルウェアの配信元や匿名化ネットワークなど）は低いレベルに分類されるため、しきい値を設定することで、これらの通信先を絞り込めます。

設定には reputation-minimum（最低レベル）と reputation-direction（評価方向、既定は destination）を使います。次の例では、送信元 IP のレピュテーションがレベル 3 以上の通信のみを許可します（レベル 1・2 の通信は破棄されます）。

config firewall policy
    edit 12
        set srcintf "wan1"
        set dstintf "internal"
        set dstaddr "all"
        set reputation-minimum 3
        set reputation-direction source
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
end

設定時に押さえておきたい挙動が 2 点あります。

• reputation-minimum を設定すると、評価方向に応じて一部のフィールドがポリシーから外れます。 方向が destination の場合は dstaddr・サービス・internet-service が、source の場合は srcaddr・internet-service-src が、ポリシーから除外されます。
• この機能は CLI で設定します。GUI からはレピュテーションの条件を直接設定できないため、対象ポリシーを CLI で編集します。

しきい値の設定によっては、正常な通信が破棄される可能性があります。 logtraffic all を有効にしたうえで、ログ監視や検証環境で影響を確認してから本適用することをおすすめします。影響の確認方法は、関連記事『FortiGate ログ管理とフォレンジックの手順』を参照してください。

確認: show firewall policy <id> | grep reputation

参考: Fortinet「IP reputation filtering」
“there are five reputation levels in the internet-service database”
（Internet Service データベースには 5 つのレピュテーションレベルがある）
https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/68937/ip-reputation-filtering

未使用ポリシーの精査

運用を続けるうちに、使われなくなったポリシーや、必要以上に広いポリシーが残りがちです。これらは攻撃面を広げるだけでなく、ポリシー一覧の見通しを悪くし、評価順の誤りにもつながります。定期的に精査し、整理することをおすすめします。

精査の手がかりになるのが、ポリシーごとのヒットカウントと最終使用日時です。GUI の「ポリシーとオブジェクト」のポリシー一覧で、ヒットカウント・最終使用・バイト数などの列を確認し、長期間一致していないポリシーを洗い出します。設計の基本で触れた logtraffic all を有効にしておくと、実際の通信状況からの判断がしやすくなります。

また、Security Rating の監査には、ポリシーまわりの点検項目が含まれます。未使用や冗長なポリシーの洗い出しに活用できます。Security Rating を使った設定全体の自己監査の進め方は、『FortiGate ハードニングの優先度と確認手順』で扱っています。

整理を進める際は、いきなり削除せず、まず対象ポリシーを無効化（set status disable）して影響がないことを確認してから削除すると、切り戻しが容易になります。 十分な観察期間を取り、業務上のまれな通信を巻き込まないように進めます。

確認: ヒットカウントと最終使用日時を点検し、対象を無効化してから削除します。

ポリシー変更時の注意（セッション再評価）

Firewall Policy を変更すると、その変更の影響を受ける既存セッションは「dirty」とフラグ付けされ、CPU によって再評価されます。再評価で最新のポリシーに適合しないと判断されたセッションは破棄されます。多数のセッションが一度に再評価されると、CPU の負荷が一時的に高まり、通信に影響する可能性があります。

この挙動は firewall-session-dirty で制御できます。

 check-all（既定）: ポリシーやルートの変更で影響を受ける既存セッションを再評価します。適合しないセッションは破棄されます。

 check-new: 既存セッションを維持し、変更を新規セッションにのみ適用します。CPU 負荷とパケットロスを抑えられますが、ポリシー変更が既存セッションに即座に反映されない点はトレードオフになります。

 check-policy-option: ポリシー単位で再評価の挙動を選べます。（ポリシー単位の設定は、VDOM レベルが check-policy-option の場合に利用できます）

config system settings
    set firewall-session-dirty check-all
end

セッションが dirty になる契機は、Firewall Policy の変更のほか、ルーティングの変更、ネットワーク関連の設定変更、関連するセキュリティプロファイルを持つポリシーでの FortiGuard 定義更新などです。ポリシーの変更は、利用率の低い時間帯やメンテナンスウィンドウで行い、既存セッションへの影響を見込んで進めることをおすすめします。 変更後の通信影響の確認方法は、関連記事『FortiGate ログ管理とフォレンジックの手順』を参照してください。

確認: show full-configuration system settings | grep firewall-session-dirty

参考: Fortinet「Policy configuration changes」
“A session flagged as dirty requires revalidation by FortiGate’s CPU”
（dirty とフラグ付けされたセッションは FortiGate の CPU による再評価を要する）
https://docs.fortinet.com/document/fortigate/7.6.0/best-practices/54033/policy-configuration-changes

まとめ

FortiGate の Firewall Policy の堅牢化は、必要な通信のみを具体的に許可し、リスクの高い通信先をレピュテーションやジオブロッキングで絞り、使われていないポリシーを整理する作業です。ポリシーの変更は既存セッションの再評価を伴うため、影響を見込んで低負荷の時間帯に進めます。設定後は Security Rating で抜け漏れを点検します。

• 既定で拒否し必要な通信のみを具体的に許可する設計
• 送信元・宛先インターフェースに ANY を使わない指定
• ジオブロッキングと ISDB によるリスクの高い通信先の制御
• IP レピュテーションのしきい値設定と通信影響の事前確認
• ヒットカウントと Security Rating による未使用ポリシーの精査
• 削除前の無効化による切り戻しの確保
• ポリシー変更時のセッション再評価と低負荷時間帯での適用

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