セキュリティ・ポリシーは、セキュリティ・ルール・ベース内でルールの集合として作成されます。
明確に定義されたセキュリティ・ポリシーは、効果的なセキュリティ・ソリューションに不可欠です。
ルール・ベースの基本原則は、「明示的に許可されないすべてのアクションは禁止する」です。 ルー ル・ベースは、どの通信トラフィックを許可して、どのトラフィックを遮断するかを決定するルー ルの集合です。 ルール・パラメータには、通信の発信元と宛先、使用可能なサービスとプロトコル、
通信を許可する時刻、トラッキング・オプションが含まれます。 SmartView Trackerのトラフィック・
ログと警報を参照することは、重要なセキュリティ管理事項です。
VPN-1はパケットを順番に検査します。 VPN-1は接続のパケットを受け取ると、それをルール・
ベースの最初のルール、2番目のルール、3番目のルールと順番に検査します。 VPN-1は適用可能な ルールを検出すると、検査を停止して、そのルールをパケットに適用します。 ルール・ベースで適 用可能なルールが見つからない場合、パケットは遮断されます。 適用されるルールは必ずしも最も 一致するルールではなく、最初に一致するルールであることに注意してください。
アクセス制御ルールの例
図1-2は典型的なアクセス制御ルールを示しています。 このルールは、任意のAlaska_LANグルー プ・ホストから任意の宛先に発信されたHTTP接続を許可し、ログに記録します。
図 1-2 アクセス制御ルールの例
ルール・ベース要素
ルールは、以下のルール・ベース要素で構成されています（すべてのフィールドが特定のルールに 定義されるわけではありません）。
表 1-1 ルール・ベース要素 Sourceと
Destination
接続の発信元と宛先を指します。 クライアント・サーバ・モデルで動作するアプリケー ションでは、Sourceはクライアント、Destinationはサーバです。 接続が許可されると、
接続を介して転送されるパケットは双方向に自由に通過します。
SourceとDestinationパラメータの否定をとることができます。つまり、特定のルールは、
指定した場所を除く、すべての接続のSource/Destinationに適用されます。たとえば、
Sourceが特定のネットワークに含まれないと指定する方が便利な場合があります。接続の
SourceまたはDestinationの否定をとるには、該当するルールのセルを右クリックして、オ
プション・メニューから［Negate Cell］を選択します。
VPN 暗号化の有無に関わらずルールをすべての接続に適用するか、VPN接続にのみ適用するかを 設定できます。 ルールをVPN接続に限定するには、該当するルールをダブルクリックして、
2つのVPNオプションのいずれかを選択します。
Service ルールを特定の事前定義済みプロトコル、サービス、またはアプリケーションに適用でき
ます。新しいカスタム・サービスを定義できます。
Action パケットを許可(Accept)、拒否(Reject)、または破棄(Drop)するかどうかを決定します。
接続が拒否されると、VPN-1はRSTパケットを接続の発信元に送信し、接続を閉じます。
パケットが破棄されると応答は送信されず、接続は最後に時間切れになります。 認証に関 するアクションの詳細については、第2章「認証」を参照してください。
Track 各種のログ記録オプションを指定します（詳細については、『SmartCenter』を参照してく
ださい）。
Install-On ルールをインストールするVPN-1ゲートウェイを指定します。 特定のルールをすべての
VPN-1ゲートウェイで実施する必要はありません。たとえば、特定のネットワーク・サー
ビスは特定のゲートウェイのみを通過させるルールを作成できます。この場合、特定の ルールを他のゲートウェイにインストールする必要はありません （詳細については、
『SmartCenter』を参照してください）。
Time このルールを実施する日付と時刻を指定します。
暗黙ルール
VPN-1は、管理者が定義するルール以外に［Policy］>［Global Properties］で定義される暗黙の
ルールも作成します。 暗黙のルールにより、各種機能を使用するために必要なゲートウェイを発着 信する通信が許可されます。 暗黙のルールの例としては、VPN-1制御接続とVPN-1ゲートウェイか らの発信パケットを許可するルールがあります。
VPN-1の暗黙ルールをルール・ベースの最初（First）、最後（Last）、または最後の前（Before Last）
に位置し、ログに記録できます。ルールは以下の順序で処理されます。
1. 最初のルール： 最初のルールは常にパケットに適用されます。他のルールを前に置くことが できないため、このルールはルール・ベースで変更または上書きできません。
2. 明示的ルール： これらは、管理者が定義するルールで、最初のルールと最後から2番目の ルールの間に置くことができます。
3. 最後の前のルール： 最後のルールが適用される前に実施する、より具体的なルールです。
4. n番目のルール： 最後に定義されたルールです。
5. 最後のルール： ルール・ベース内の最後のルールの後で実施されるルールで、通常、すべて のパケットを拒否し、何も影響を与えません。
6. 暗黙の破棄ルール： ログに記録されません。
IP スプーフィングの防止
IPスプーフィングは、高いアクセス権を持つネットワーク・ノードからパケットが発生したかのよ うに見せるため、パケットのIPアドレスを変更し、許可されていないアクセス権を侵入者が取得し ようとする手法です。
注： すべての通信が明確な発信元から発生しているかどうかを確認することが重要です。
アンチ・スプーフィング保護は、パケットがゲートウェイの正しいインタフェースに発着信するこ とを検証します。 アンチ・スプーフィング保護は、パケットが指定された内部ネットワーク・イン タフェースから送信されているかを確認します。また、パケットがルーティングされた後、それが 適切なインタフェースを通過することを検証します。
外部インタフェースから来たパケットが偽の内部IPアドレスを持っていても、VPN-1のアンチ・
スプーフィング機能が不正なインタフェースから来たことを検知するので遮断されます。 図1-3に アンチ・スプーフィング・プロセスの仕組みを示します。
図 1-3 アンチ・スプーフィング・プロセス
Alaska_GWでは、VPN-1は以下のことを確認します。
• インタフェースIF1へのすべての着信パケットはインターネットから送信されている。
• インタフェースIF2へのすべての着信パケットはAlaska_LAN、Alaska_RND_LAN、または
Florida_LANから送信されている。
Alaska_RND_GWでは、VPN-1は以下のことを確認します。
• インタフェースIF3へのすべての着信パケットはAlaska_LAN、Florida_LAN、またはイン ターネットから送信されている。
• インタフェースIF4へのすべての着信パケットはAlaska_RND_LANから送信されている。
アンチ・スプーフィングを設定する場合は、インタフェース・トポロジの定義でインタフェースが インターネットに接続されている（Externalとして定義する）か、内部ネットワークに接続されて いる（Internalとして定義する）か指定する必要があります。 図1-3に、ゲートウェイ・インタフェー スがインタフェース・トポロジ定義の内部または外部のどちらであるかを示します。
アンチ・スプーフィング保護から特定の内部アドレスを除外
状況によっては、内部ネットワークに属する送信元アドレスを持つパケットを、外部インタフェー ス経由でゲートウェイに送信できるようにする必要があります。これは、外部アプリケーションが 内部IPアドレスを外部クライアントに割り当てる場合に役立つことがあります。この場合、指定し た内部ネットワークからのパケットに対してアンチ・スプーフィング・チェックを行わないように 指定できます。たとえば、図1-3では、Alaska_RND_LANに含まれる発信元アドレスのパケットを インタフェースIF1に送信できるように指定できます。
適正なアドレスとは
適正なアドレスとは、VPN-1ゲートウェイ・インタフェースへの入力を許可されるアドレスです。
適正なアドレスはネットワーク・トポロジによって決まります。 VPN-1アンチ・スプーフィング保 護を設定する場合、管理者はインタフェースの背後にある適正なIPアドレスを指定します。［Get Interfaces with Topology］オプションは、自動的にインタフェースとそのトポロジを定義し、ネッ トワーク・オブジェクトを作成します。VPN-1は、ルーティング・テーブルのエントリを読み取る ことによってこの情報を取得します。
追加情報
アンチ・スプーフィング保護の計画の詳細については、43ページの「スプーフィング保護」を参照 してください。
アンチ・スプーフィングの設定の詳細については、48ページの「アンチ・スプーフィングの設定」を 参照してください。
マルチキャスト・アクセス制御
このセクションの構成
マルチキャスト IP について
マルチキャストIPを使用すると、1つのメッセージを定義済みの受信者のグループに送信すること ができます。 例としては、分散型の会議に参加している一連のホストへのリアルタイムのオーディ オやビデオの配信があります。
マルチキャストは、選択した周波数にチューナを合わせて情報を受信するラジオやテレビに似てい ます。マルチキャストでは興味のあるチャンネルだけを聞き、他のチャンネルは聞きません。
IPマルチキャスト・アプリケーションは、各データグラムの1つのコピー（IPパケット）を受信し たいコンピュータのグループ宛に送信します。この方法では、データグラムを1人の受信者（ユニ キャスト・アドレス）ではなく、受信者のグループ（マルチキャスト・アドレス）に送信します。
ネットワーク内のルータは、データグラムを必要としているルータとホストにのみ転送します。
IETF（Internet Engineering Task Force）で、以下を定義するマルチキャスト通信標準が開発され ています。
• マルチキャスト・ルーティング・プロトコル
• 動的な登録
• IPマルチキャスト・グループのアドレス指定
マルチキャスト・ルーティング・プロトコル
マルチキャスト・ルーティング・プロトコルは、マルチキャスト・グループ間で情報を伝達します。
マルチキャスト・ルーティング・プロトコルの例として、PIM（Protocol-Independent Multicast）、
DVMRP（Distance Vector Multicast Routing Protocol）、MOSPF（Multicast Extensions to OSPF）
などがあります。
マルチキャストIPについて 37ページ
マルチキャスト・ルーティング・プロトコル 37ページ
IGMPを使用した動的な登録 38ページ
IPマルチキャスト・グループのアドレス指定 38ページ インタフェースごとのマルチキャストの制限 39ページ