FortiGate 管理アクセス制限の手順｜Trusted Host と Local-in-Policy

はじめに

管理者アカウントや認証を強化しても、管理インターフェースが広く露出していれば、攻撃者がログインを試みる入り口は残ります。FortiGate の管理面の堅牢化では、「どのインターフェースで・どのポートで・どこから」管理接続を受けるかを絞り込むことが重要になります。

本記事では、FortiGate の管理アクセスを制限する手順を CLI 中心にまとめます。アカウント名・パスワード・2 要素認証といった認証の強化は関連記事『FortiGate 管理者アカウントと認証設定の手順』で、設定全体の優先度は『FortiGate ハードニングの優先度と確認手順』で扱っています。

管理アクセスの制限は、外部インターフェースで管理を受けない構成を基本に、許可するプロトコルを HTTPS・SSH へ絞り、接続元を Trusted Host や Local-in-Policy で限定する、という流れで整理できます。以降では各設定を順に扱います。

外部インターフェースの管理アクセス制限

管理インターフェースの露出を抑える第一歩は、インターフェースごとに許可する管理アクセス（allowaccess）を見直すことです。

管理アクセスを HTTPS と SSH のみに絞る

外部（インターネット接続）インターフェースでは、可能な限り管理アクセスを許可しない構成を推奨します。理想的には、管理は専用の管理インターフェースや VPN 経由など、信頼できる経路から行います。

外部インターフェースの管理アクセスを無効化するには、allowaccess を解除します。

config system interface
    edit <external-interface>
        unset allowaccess
    next
end

管理を受ける内部インターフェースでも、HTTP や Telnet は使わず、HTTPS と SSH のみを許可します。

config system interface
    edit <mgmt-interface>
        set allowaccess https ssh
    next
end

GUI では「ネットワーク」>「インターフェース」で各インターフェースを編集し、管理アクセスの項目から HTTP・Telnet・PING などの不要な許可を外します。外部からの管理を開放せざるを得ない場合でも、後述の Trusted Host や Local-in-Policy で接続元を限定することをおすすめします。

確認: show system interface <name> | grep allowaccess

参考: Fortinet「Hardening your FortiGate」
“never allow HTTP or Telnet administrative access to a FortiGate interface”
（FortiGate インターフェースへの HTTP・Telnet 管理アクセスは許可しない）
https://docs.fortinet.com/document/fortigate/6.4.0/hardening-your-fortigate/582009/system-administrator-best-practices

管理ポートの非標準化

管理アクセスの既定ポート（HTTPS: 443・SSH: 22）は広く知られており、無差別なスキャンの最初の対象になりやすいポートです。非標準ポートへ変更すると、的を絞った接続試行をある程度避けられます。

config system global
    set admin-sport 7734
    set admin-ssh-port 2345
end

変更後は、接続時に新しいポート番号を指定します。たとえば HTTPS を 7734、SSH を 2345 にした場合、https://<ip-address>:7734、ssh admin@<ip-address>:2345 で接続します。GUI では「システム」>「設定」>「管理者設定」で HTTPS ポートと SSH ポートを変更できます。

変更時は、ほかのサービスが使うポートと競合しないことを確認します。たとえば SSL VPN を 443 で公開している場合、管理 HTTPS ポートを別ポートへ移すといった調整が必要になります。

確認: show full-configuration system global | grep -e admin-sport -e admin-ssh-port

参照: 非標準ポートと管理アクセスの考え方は Best Practices（FortiOS 8.0）の Hardening を確認しています。
https://docs.fortinet.com/document/fortigate/8.0.0/best-practices/555436/hardening

管理セッションのタイムアウトと SSH grace time

放置された管理端末の悪用や、SSH 接続後の認証待ち時間を悪用したブルートフォースを抑えるため、セッションのタイムアウトと認証猶予時間を短く保ちます。

管理者のアイドルタイムアウトは、操作のない管理セッションを自動的に切断するまでの時間です。出荷時設定: 5 分。ベストプラクティスとしては、既定の 5 分のまま維持する運用が推奨されます。

config system global
    set admintimeout 5
end

SSH の grace time は、接続確立から認証完了までに許可される猶予時間です。出荷時設定: 120 秒（範囲は 10〜3600 秒）。短くすることで、総当たり攻撃が成立する余地を減らせます。

config system global
    set admin-ssh-grace-time 30
end

確認: show full-configuration system global | grep -e admintimeout -e admin-ssh-grace-time

HTTPS 管理アクセスの TLS と HTTP リダイレクト

GUI への HTTPS 管理アクセスで使う TLS バージョンと、HTTP から HTTPS へのリダイレクトを確認します。いずれも出荷時に堅牢側の設定ですが、過去の変更で緩んでいないかを点検します。

出荷時設定: admin-https-ssl-versions は tlsv1-2 tlsv1-3、admin-https-redirect は enable。より新しい TLS 1.3 のみに絞る運用や、システムごとに利用バージョンを選ぶこともできます。

config system global
    set admin-https-ssl-versions tlsv1-2 tlsv1-3
    set admin-https-redirect enable
end

確認: show full-configuration system global | grep -e admin-https-ssl-versions -e admin-https-redirect

なお、HTTPS・SSH・TLS・SSL 全体で使う暗号スイートの強度（strong-crypto・ssl-static-key-ciphers・dh-params など）は、本記事ではなく関連記事『FortiGate 暗号化と物理アクセスの堅牢化』にまとめます。本セクションは管理アクセスに用いる TLS バージョンとリダイレクトの確認に絞っています。

参照: TLS バージョンとリダイレクトの既定値は Hardening your FortiGate を確認しています。
https://docs.fortinet.com/document/fortigate/6.4.0/hardening-your-fortigate/582009/system-administrator-best-practices

Trusted Host による接続元の制限

Trusted Host は、管理者がログインできる送信元アドレスを制限する仕組みです。HTTPS・SSH・SNMP など、多くの管理アクセスに適用されます。設定すると、正しい資格情報でも信頼できないホストからのログインは破棄されます。

管理者アカウントには最大 10 個の Trusted Host を指定できます。アカウント側の設定手順は関連記事『FortiGate 管理者アカウントと認証設定の手順』で扱うため、ここでは接続元制限としての観点に絞ります。

config system admin
    edit <administrator-name>
        set trustedhost1 172.25.176.23 255.255.255.255
        set trustedhost2 172.25.177.0 255.255.255.0
    next
end

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

 リストは順番に評価され、最初に一致したエントリで動作します。 ファイアウォールポリシーと同様に、具体的なアドレスをリストの上位に、より広いアドレスを下位に置きます。各 Trusted Host の既定値は 0.0.0.0 0.0.0.0（すべてに一致）のため、上位に 0.0.0.0 0.0.0.0 が残っていると制限が効きません。

 ping は Trusted Host の例外です。 インターフェースで ping を許可している場合、Trusted Host の設定にかかわらず、どの IP アドレスからの ping にも応答します。ping も制限したい場合は、後述の Local-in-Policy を併用します。

 Trusted Host を設定できるのはローカル管理者と REST API 管理者のアカウントです。SAML ベースの SSO 管理者アカウントには直接設定できません。

確認: show system admin | grep trustedhost

参考: Fortinet「Administrator account options」
“FortiOS only accepts that administrator’s login from one of the trusted hosts”
（FortiOS は Trusted Host のいずれかからの管理者ログインのみを受け付ける）
https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/14906/administrator-account-options

Local-in-Policy による管理アクセスとサービスの制御

Trusted Host が管理者アカウント単位で接続元を絞るのに対し、Local-in-Policy は FortiGate インターフェース宛の受信トラフィックを、送信元・宛先・インターフェース・サービスの単位で制御します。Trusted Host では絞れない ping を遮断したり、VPN や NTP など管理アクセス以外のサービスを制御したりできる点が違いです。

注意したいのは、通常のファイアウォールポリシーと異なり、Local-in-Policy には暗黙の deny が存在しないことです。特定の送信元だけを許可したい場合は、許可ルールの下に明示的な拒否ルールを置く必要があります。設定を誤ると自身の管理接続も遮断され得るため、コンソールアクセスを確保したうえで、メンテナンスウィンドウでの適用と確認をおすすめします。

ping を Trusted Host のみに許可する

ping は Trusted Host の例外で全ネットワークに応答するため、送信元を絞るには Local-in-Policy を使います。特定サブネットからの ping のみを許可し、それ以外を拒否する例は次のとおりです。

config firewall address
    edit "mgmt_subnet"
        set subnet 172.16.200.0 255.255.255.0
    next
end
config firewall local-in-policy
    edit 1
        set intf "port1"
        set srcaddr "mgmt_subnet"
        set dstaddr "all"
        set action accept
        set service "PING"
        set schedule "always"
    next
    edit 2
        set intf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "PING"
        set schedule "always"
    next
end

許可ルール（edit 1）だけでは他の送信元からの ping は遮断されません。暗黙の deny がないため、拒否ルール（edit 2）を許可ルールの下に明示的に置く点がポイントです。

確認: show firewall local-in-policy

未使用の開放ポートを閉じる

利用していないサービスのポートを Local-in-Policy で閉じると、FortiGate 自身が受信する通信を絞り込めます。たとえば wan1 のすべての ICMP を拒否する例です。

config firewall local-in-policy
    edit 1
        set intf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "ALL_ICMP"
        set schedule "always"
    next
end

service を BGP に変えれば BGP ポート（179/TCP）を、必要なサービス名に変えれば該当ポートを閉じられます。なお、悪意ある送信元の遮断については、FOS 7.4.4 以降では既定の Local-in-Policy が用意されており、ISDB の Malicious-Malicious.Server・Tor-Exit.Node・Tor-Relay.Node を送信元として、全インターフェース宛の通信を遮断します。これをベースラインとして活用できます。

また、Local-in-Policy では virtual-patch を有効にして、FortiOS 宛の既知脆弱性を緩和することもできます。詳細は関連記事『FortiGate 仮想パッチによる脆弱性緩和』で扱います。

参考: Fortinet「Local-in policy」
“local-in policies control inbound traffic that is going to a FortiGate interface”
（Local-in ポリシーは FortiGate インターフェース宛の受信トラフィックを制御する）
https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/363127/local-in-policy

まとめ

FortiGate の管理アクセス制限は、管理を受けるインターフェース・ポート・接続元を段階的に絞り込む作業です。外部インターフェースで管理を受けない構成を基本に、許可するプロトコルを HTTPS・SSH へ限定し、接続元を Trusted Host と Local-in-Policy で制御すると整理しやすくなります。Local-in-Policy は柔軟な一方でロックアウトのリスクがあるため、コンソールアクセスを確保したうえで適用します。

• 外部インターフェースでの管理アクセスを受けない構成
• 管理プロトコルを HTTPS と SSH のみに限定
• 管理ポートの非標準化とポート競合の確認
• アイドルタイムアウトと SSH grace time の短縮
• Trusted Host による管理者ログインの接続元制限
• ping や未使用ポートの Local-in-Policy による遮断
• 暗黙の deny がない Local-in-Policy での明示的な拒否設定

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