Firebox 構成のベストプラクティス
組織内ネットワークを保護するため、Firebox は、ファイアウォール ポリシーによって具体的に許可されていないすべてのパケットを拒否します。それぞれのファイアウォール ポリシーは、パケットの発信元・送信先、またはパケットに使用される TCP/IP ポートやプロトコルなどの要因に基づいてトラフィックを許可または拒否するように Firebox に指示する一連のルールを定義します。
このトピックには以下が含まれています。
- 推奨される既定の構成
- ファイアウォール ポリシーの基本
- ポリシー構成のベストプラクティス
- ポリシーのトラブルシューティングのヒント
- ネットワークと VPN 構成のベストプラクティス
- 証明書のベストプラクティス
推奨される既定の構成
Firebox を設定するために Web Setup Wizard または Quick Setup Wizard を実行すると、セットアップ ウィザードは既定の ファイアウォール ポリシーを自動的に構成し、ライセンス付与されたセキュリティ サービスを推奨された設定を使って有効化します。
お使いの新しい Firebox が v12.0.1 よりも前の Fireware バージョンを実行している場合は、Fireware をアップグレードしてから Firebox をリセットし、セットアップ ウィザードを再実行して推奨される既定のプロキシ ポリシーとセキュリティ サービスを自動的に有効化することをお勧めします。
推奨された既定のポリシーを使って新しい Firebox を設定するには、以下の手順を実行します：
- Web Setup Wizard または WSM Quick Setup Wizard を実行し、基本構成を使用して Firebox を設定します。
詳細については、Firebox Setup Wizards の詳細 を参照してください。 - Firebox にインストールされた Fireware のバージョンを確認します。
- インストールされた Fireware のバージョンが v12.0.1 以前の場合は、以下の手順を実行します：
- Firebox を Fireware v12.0.1 以降にアップグレードします。詳細については、Fireware OS または WatchGuard System Manager をアップグレードする を参照してください。
- Firebox を工場出荷時の既定設定にリセットします。詳細については、Firebox をリセットする を参照してください。
- Web Setup Wizard または Quick Setup Wizard を再実行します。
ウィザードが既定のプロキシ ポシリーで Firebox を構成し、ライセンス付与されたセキュリティ サービスを有効化します。
セットアップ ウィザードは以下の既定ポリシーを追加します：
- FTP-proxy、Default-FTP-Client プロキシ アクションを使用
- HTTP-proxy、Default-HTTP-Client プロキシ アクションを使用
- HTTPS プロキシ、Default-HTTPS-Client プロキシ アクションを使用
- WatchGuard 証明書ポータル (Fireware v12.3 以降)
- WatchGuard Web UI
- Ping
- DNS
- WatchGuard
- 発方向(O)
これらの既定ポリシーで、Firebox は：
- 外部ネットワークから信頼済みネットワークや任意ネットワーク、または Firebox への接続を許可しません
- 信頼済みネットワークおよび任意ネットワークからの Firebox への管理接続のみを許可します
- 送信 FTP、HTTP および HTTPS トラフィックを、推奨されるプロキシ アクションの設定を使用して検査します
- Application Control、WebBlocker、Gateway AntiVirus、Intrusion Prevention、Application Control、Reputation Enabled Defense、Botnet Detection、Geolocation および APT Blocker セキュリティ サービスを使って信頼済みおよび任意ネットワークを保護します
- 信頼済みネットワークおよび任意ネットワークからの継続的な FTP、Ping、DNS、TCP および UDP 接続を許可します
既定のファイアウォール ポリシーやサービス構成についての詳細は、次を参照してください：Setup Wizard の既定のポリシーと設定。
ファイアウォール ポリシーの基本
既定のポリシーを編集したり新しいポリシーを追加して、Firebox が承認された接続のみを許可するようにすることができます。ファイアウォール ポリシーを編集したり新たに作成する前に、いくつかのポリシーの基本を理解しておくことが重要です。
ポリシーの種類
ファイアウォール ポリシーには 2 種類があります。それぞれが、異なる詳細レベルで接続を検査します。
パケット フィルタ ポリシー - パケット ヘッダーのみを検証します
パケット フィルタは、各パケットの IP および TCP/UDP ヘッダーを検査しますが、その内容は検査しません。
プロキシ ポリシーまたはアプリケーション レイヤ ゲートウェイ (ALG) - パケット ヘッダーと内容の両方を検証します。
プロキシ ポリシーまたは ALG は、各パケットを順番に開き、ネットワーク レイヤ ヘッダーを削除し、パケットのペイロードを検査します。プロキシ ポリシーまたは ALG を構成する際には、プロキシ アクションを選択し、その内容の特性に基づいてルールやとるべきアクションを構成します。詳細については、プロキシ ポリシーと ALG について を参照してください。
既定の構成では、Firebox がコンテンツを検査してライセンス付与されたセキュリティ サービスを使ってネットワークを保護することができるようにプロキシ ポリシーを使用します。
ポリシー プロパティ
ポートとプロトコル
ポリシーはリスニングする対象のポートとプロトコルに対し定義されます。ポリシーを追加する際には、選択するポリシー テンプレートにより、どのポートとプロトコルにポリシーが適用されるかが指定されます。ポリシーで編集することができないプロパティはこれらのポートとプロトコルのみです。
送信元と送信先
ポリシーが適用されるのは、ポリシーで送信元 (From) と送信先 (To) の両方に一致する接続のみです。送信元または送信先にはエイリアス、ユーザー、グループ、IP アドレス および FQDN を含めることができます。
処置 (ファイアウォール アクション)
処置は、ポリシー内のルールに当てはまる接続をポリシーが許可するか拒否するかを指定します。ポリシーを構成して接続を 許可 または 拒否 することができます。
ポリシー送信元、送信先、および処置の構成方法の詳細については、次を参照してください：ポリシーのアクセス ルールを設定する。
ポリシーの優先付け
優先順位 とは、Firebox がネットワーク トラフィックを検査して、ポリシー ルールを適用する順位です。既定により、Firebox ポリシーは自動順位モードで構成されます。自動順位モードでは、Firebox は、次のポリシー プリパティの比較に基づいて、ポリシーを最も特定のものから最も一般的なものの順に自動的に並べ替えます：
- ポートとプロトコル
- 送信元と送信先
- 処置
- スケジュール
リスト内の順位がより高いポリシーは、優先順位がより高くなります。Firebox がパケットを受信すると、パケットの属性に一致する最高の優先順位のポリシーが適用されます。2 つのポリシーの詳細レベルが同じ場合に自動順位モードが有効化されていると、プロキシ ポリシーがパケット フィルタ ポリシーよりも優先されます。ポート、プロトコル、送信元と送信先が一致する優先順位が最も高いポリシーのみがパケットに適用されます。また、自動順位モードを無効にして、ポリシーの順位を手動で変更することもできます。これには、構成に多数のポリシーがある場合は特に、慎重な管理が必要です。
推奨事項：自動順位モードを、それが特定の状況に適合しなくなるまで使用します。このモードは大多数の実装で正常に機能します。
同一のポート/プロトコルに対し、送信元や送信先が異なる複数のポリシーを追加して、異なるユーザーやグループ、ネットワークのためのさまざまなレベルのアクセスをネットワーク リソースに許可することができます。例えば、特定の部門のために HTTP プロキシ ポリシーを構成して、優先順位がより低い既定の HTTP プロキシ ポリシーよりも限定的な、またはより広範なアクセスをリソースに許可することができます。
ポリシーの優先順位および自動順位モードを無効化にする方法の詳細については、次を参照してください：ポリシーの優先順位について。
ポリシー構成のベストプラクティス
ポリシー名のカスタマイズ
既定の Firebox 構成はポリシーの標準名を使用します。既定のポリシー名はポリシーが扱うトラフィックのタイプを示しますが、特に同一タイプのポリシーが複数ある場合は、ネットワーク環境ではあまり意味をなさない可能性があります。
推奨事項： ポリシーをより把握しやすく、維持しやすくするため、各ポリシーには、そのポリシーの目的、適用の対象となるユーザーやネットワーク、またはいつポリシーが有効になるかなどのその他の固有の属性が分かるような、意味をなしやすい名前を付けます。
ファイアウォール ポリシーの範囲を制限する
既定では、ファイアウォール ポリシーは組み込み済みのエイリアス Any-External、Any-Trusted、Any-Optional および Any を使用します。これらのエイリアスを使って構成されたポリシーは、必要以上に多い送信元や送信先の接続を許可する可能性があります。ネットワーク接続をより高度に制御するには、各ポリシー内の送信元と送信先を評価して、そのポリシーが必要以上の接続元からの接続や送信先への接続を許可しないようにします。
推奨：
- 各ポリシーで、できるだけ制限された送信元と送信先を構成します。
- Any エイリアスは、ポリシーでは使用しないでください (既定の ping および BOVPN-Allow.in と BOVPN-Allow.out ポリシーは除く)。
- Any、Any-External、Any-Optional または Any-Trusted のエイリアスを含む全てのポリシーをレビューします。
- 推奨事項：各ポリシーのエイリアスが、許可する接続に本当に必要であることを確認します。
- 可能な場合は、これらのエイリアスをより具体的な送信元や送信先に置き換えて、ポリシーの範囲をより限定的にします。
自動的に生成された一部のポリシーの範囲を限定的にする状況の例をいくつかここに示します。
既定の DNS ポリシーで送信先を編集する
既定の DNS ポリシーは Any-Trusted および Any-Optional から Any-External への接続を許可します。
推奨： このポリシーの範囲を限定的にするには、DNS 設定で外部 DNS サーバーの IP アドレスまたは FQDN だけを含めるように送信先を変更することができます。
Firebox 管理ポリシーで送信元を編集する
既定の WatchGuard および WatchGuard Web UI ポリシーではAny-Trusted および Any-Optional からの管理接続が許可されます。
推奨：これらのポリシーから Any-Optional を削除すれば、任意ネットワークからの管理接続を防止することができます。範囲をさらに制限するには、Any-Trusted を削除し、Firebox が管理接続を受け入るようにする具体的なサブネットまたは IP アドレスを追加します。
既定の Mobile VPN アクセス ポリシーの送信先を編集する
Mobile VPN with SSL または Mobile VPN with L2TP を有効化すると、自動的に生成されたファイアウォール ポリシーにより、VPN 構成で指定したユーザーやグループから送信先 Any への接続が許可されます。
自動的に生成された VPN アクセス ポリシーは：
- Mobile VPN with SSL の場合：Allow SSLVPN-Users
- Mobile VPN with L2TP の場合：Allow L2TP-Users
VPN 設定で構成した許可されたリソースは、VPN クライアントがどの接続を通じてトンネルを通過するかをコントロールします。許可されたリソースは VPN ポリシーの送信先ではありません。Mobile VPN グループ内のユーザーが VPN のない Firebox に対し認証を行った場合、Firebox はそのユーザーを VPN グループのメンバーとして認識し、VPN ポリシーはそのユーザーから任意の送信先への接続を許可することができます。
推薦： これらの既定のポリシーを編集して記述の範囲を限定します。Any エイリアスを削除し、Firebox が VPN ユーザーによる接続を許可する具体的なリソースを追加します。
エイリアスの詳細については、エイリアスについて および エイリアスを作成する を参照してください。
送信ポリシーを無効にする
既定の Firebox 構成には 送信 パケット フィルタ ポリシーが含まれています。送信ポリシーは、ネットワーク上の信頼済みまたは任意の送信元から外部ネットワークへの TCP および UDP 接続をすべて許可します。発信ポリシーはパケット フィルタ ポリシーでありプロキシ ポリシーではないので、Firebox を経由するトラフィックを調べるときにコンテンツをフィルタしません。送信ポリシーは、Firebox が、他のいずれのポリシーにも適合しない送信 TCP および UDP 接続を許可するためにあります。
推薦： 許可させたい接続のみを Firebox が許可するようにするには、送信ポリシーを無効にすることをお勧めします。これはベストプラクティスですが、それには注意深い計画とフォローアップが必要です。送信ポリシーを削除する前に、Firebox で許可する送信接続のポリシーを追加しておく必要があります。許可する各タイプの送信トラフィックに対し別々のポリシーを追加するか、お使いのネットワークから許可する送信接続に必要な具体的なポートのカスタム パケット フィルタを作成することができます。
慎重に計画した場合でも、送信ポリシーを無効にした後に、許可してもらいたい一部の送信接続を Firebox が拒否する可能性があります。これらの問題のトラブルシューティングに備え、必要に応じてポリシーを追加して、Firebox を通じた必要な送信接続を許可します。
送信ポリシーを無効にした後、時間を費やして問題点を特定し、ファイアウォール ポリシーを更新して、承認された送信接続を許可するよう計画すべきです。このプロセスには時間がかかりますが、ネットワーク上のトラフィックのタイプを把握し、それをコントロールする能力も得られます。
HTTPS コンテンツ インスペクションを有効化する
HTTPS プロキシでは、インスペクション アクションを選択してコンテンツ インスペクションを有効化することができます。コンテンツ インスペクションを有効化すると、Firebox が HTTPS 接続を解読し、そのコンテンツを調べ、続いて各ネットワーク クライアントが信用する CA によって署名された証明書を使った接続により、再暗号化します。コンテンツ インスペクションは、ネットワーク トラフィックのコンテンツを調べてアクションをとるためにプロキシを有効化します。
アプリケーションによってはコンテンツ インスペクションを中間者攻撃とみなし、それによりアプリケーションが正常に機能しなくなくなることがあります。HTTPS プロキシ アクションが、コンテンツ インスペクションと互換性のないアプリケーションと関連付けられたドメインのトラフィックを検証しないように構成する必要があります。
注意深く計画した場合でも、アプリケーションによっては、コンテンツ インスペクションを有効化した後に機能しなくなります。重要なアプリケーションは直ちにテストし、インスペクションをバイパスするのに必要なドメイン名ルールを追加するよう計画します。
HTTPS コンテンツ インスペクションが有効化された状態では正常に機能しない一部のアプリケーションには、以下が含まれます：
- Microsoft サービス (Office Online、Skype、Teams、Exchange、SharePoint、OneDrive、Product Activation)
- Apple サービス (iTunes、iCloud、App Store)
- Adobe サービス (Creative Cloud、Sign)
- その他のサービス (Facebook、LinkedIn、Dropbox、Okta)
推薦： コンテンツ インスペクションを有効化し、プロキシ アクションを構成して、互換性のないアプリケーションのインスペクションをバイパスします。
- HTTPS クライアント プロキシ アクションで、HTTPS コンテンツ インスペクションを有効化します。詳細については、HTTPS プロキシ：コンテンツ インスペクション を参照してください。
- コンテンツ インスペクション設定で、事前定義されたコンテンツ インスペクションの例外を有効化します。HTTPS プロキシは、事前定義された例外リストにあるドメインのトラフィックは検査しません。例外は、コンテンツ インスペクションが、ドメイン名ルールの手動構成なしに有効化される場合に、多数のサービスが正常に機能するようにします。
事前定義されたコンテンツ インスペクションの例外は、Fireware v12.1 以降でサポートされています。
- 重要なアプリケーションをネットワークで直ちにテストし、コンテンツ インスペクションが有効化された状態で機能しないものを特定します。
- Fireware のバージョンが事前定義されたコンテンツ インスペクションの例外をサポートしていない場合、または事前定義された例外リストにないアプリケーションのコンテンツ インスペクションをバイパスしたい場合は、アプリケーションの接続先ドメインのドメイン名ルールを追加します。
- アプリケーションと関連付けられているドメイン名を割り出します。
- 許可 アクションを含むドメイン名ルールを、それらのドメインのバイパス インスペクションに追加します。
ドメイン名ルールの追加方法の詳細については、次を参照してください：HTTPS プロキシ：ドメイン名ルール。
ポリシーのトラブルシューティングのヒント
構成に多数のポリシーが含まれている場合は、どのポリシーが特定の接続に適用されるのかを把握するのが困難な場合があります。ポリシーのトラブルシューティングに役立つヒントをいくつか紹介します。
ログ メッセージを検査する
Firebox は、デバイスを通過するトラフィックにパケット フィルタおよびプロキシ ルールを適用するときにトラフィック ログ メッセージを送信します。ログ メッセージを並べ替えてフィルタリングすれば、Firebox が接続を拒否した理由を明かすことができます。
ログ メッセージの読み方については、次を参照してください：ログ メッセージを読み取る。
既定により、ポリシーが接続を拒否すると、Firebox はトラフィック ログ メッセージを送信します。また、許可された接続のログ メッセージを送信するようポリシーを構成することもできます。これは次のようなことを行うのに役立ちます：
- 受信ポリシーが組織内サーバーへの接続を許可することを確認する
- カスタム送信ポリシーが接続を許可することを確認する
すべてのポリシーに対し許可された接続のログ記録を有効化することは、多数のログ メッセージが生成されてしまうため、お勧めしません。これによって Dimension Log Server データベースがより短時間で一杯になり、Firebox のパフォーマンスに著しく影響する可能性があります。
ポリシーでログ記録を構成する方法の詳細については、次を参照してください：ポリシーのログ記録および通知を構成する。
ポリシー チェッカーを使用する
接続にどのポリシーが適用されるかを判断するのに使用できるもう一つのツールは、Fireware Web UI のポリシー チェッカーです。
詳細については、ポリシーを見つけるためにポリシー チェッカーを使用する を参照してください。
ネットワークと VPN 構成のベストプラクティス
カスタム インターフェイス名
既定の Firebox 構成はインターフェイスの標準名を使用します。
推薦： 構成をより理解および維持しやすくするため、それぞれのインターフェイスに接続先のネットワークを記述した名前を付けることをお勧めします。
ホーム ネットワークで一般的に使用されない内部 IP アドレス範囲を構成する
企業ネットワークやゲスト ネットワークでは、プライベート ネットワークの範囲に 192.168.0.0/24 または 192.168.1.0/24 を使用しないことをお勧めします。これらの範囲は、一般的にホーム ネットワークで使用されます。
Mobile VPN ユーザーに、企業ネットワーク範囲と重複するホーム ネットワーク範囲がある場合、そのユーザーからのトラフィックは VPN トンネルを通過しません。この問題を解決するには、以下を実行することをお勧めします：新しいローカル ネットワーク範囲に移行する。
複数の DNS サーバーを構成する
Firebox で複数のドメイン名システム (DNS) サーバーを構成することが重要です。DNS サーバーは Mobile VPN およびネットワーク クライアント、ならびにセキュリティ サービスにより、接続する必要がある接続先サーバー名を解決するために使用されます。
推薦： DNS サーバーがネットワークで必ず利用可能であるようにするため、プライベート IP アドレスを使ったものと、パブリック IP アドレスを使ったものの 2 つの DNS サーバーを構成することをお勧めします。優先順位がより高くなるように、プライベート DNS サーバーを最初にリストすることをお勧めします。
DNS サーバーはネットワーク設定に追加します。詳細については、ネットワーク DNS および WINS サーバーを構成する を参照してください。
非重複 DNS 仮想アドレス プールを構成する
Mobile VPN with IPSec、L2TP、SSL または IKEv2 を構成する際には、VPN クライアントの IP アドレス プールを指定する必要があります。
推奨：
- VPN クライアントの IP アドレス プールが構成内の他の IP アドレスと重複していないことを確認します。
- 複数のサイトでモバイル VPN を構成している場合は、各サイトにあるモバイル VPN の IP アドレス プールが他のサイトのプールと重複していないことを確認してください。
- モバイル VPN の IP アドレス プールには、プライベート ネットワークの範囲である 192.168.0.0/24 および 192.168.1.0/24 を使用しないでください。これらの範囲は、一般的にホーム ネットワークで使用されます。Mobile VPN ユーザーに、企業ネットワーク範囲と重複するホーム ネットワーク範囲がある場合、そのユーザーからのトラフィックは VPN トンネルを通過しません。この問題を解決するには、以下を実行することをお勧めします：新しいローカル ネットワーク範囲に移行する。
証明書構成のベストプラクティス
PKI を使って Firebox Certificate を作成する
既定では、 Firebox は Fireware Web UI とプロキシコンテンツのインスペクションのための管理セッション データおよび認証試行を確保するために、自己署名証明書を作成します。コンテンツ インスペクションのために使用した証明書が一意であり、名前にデバイスのシリアル番号および証明書の作成時間が含まれていることを確認します。これらの証明書は信頼される認証機関 (CA) によって署名されておらず、有効なドメイン名や IP 情報が含まれてていないため、ネットワーク上のユーザーは Web ブラウザでセキュリティ警告のみしか目にしません。
推薦： 既定の自己署名証明書をネットワーク クライアントにより信頼された署名された証明書に置き換えます。ローカル プライベート キー インフラストラクチャ (PKI) を使って、Web サーバーやプロキシ認証証明書などの Firebox によって使用される内部証明書を生成します。
これはいくつかのメリットを提供します：
- Firebox で証明書を作成するよりも、内部 PKI を使って証明書を実装する方が簡単です。
- サードパーティ ソフトウェア (Active Directory など) を使って証明書を実装する方が、それを各ネットワーク クライアントに手動でインストールよりも簡単です。
- ネットワーク クライアントがローカル PKI 認証機関を信頼する場合は、Firebox に発行される証明書も自動的に信頼します。
- Firebox を置き換えた場合、ネットワーク クライアントに証明書を再実装する必要はありません。
Firebox が証明書をどのように使用するかの詳細については、次を参照してください：証明書について。