パートナー企業モデルは、相互に接続された 2 つのネットワークから成り、サーバーは、内部ネットワーク外のホストから発信されたトラフィックを保護します。
始める前に
このモデルの説明では、以下のステートメントおよび概念を取り扱います。
- 動的ホスト間 IKE ネゴシエーション
- 鍵交換規則
- ローカルおよびリモートのセキュリティー・エンドポイント
- Location と Identity でのワイルドカードの使用
- IpLocalStartAction
- 細分性
- RSA シグニチャー・ピア認証
- 証明書と認証局
- オンデマンド活動化
- リモート活動化
図 1 は、セキュリティー・モデル・ネットワークのパートナー企業部分を示しています。
パートナー企業モデルは内部ネットワーク・モデルに似ていますが、セキュリティーの必要性が大きくなるため、データの認証と暗号化を必要とする接続数が増加します。一部のサービスは平文形式でも許可されますが、機密データについては IPSec 保護が必要です。ある接続に IPSec を適用するには、その接続経由で流れるトラフィックは、ipsec アクションを伴う IP フィルター規則に一致していなければなりません。
この例では、接続ネットワーク (9.4.0.0/16) 経由の非トラステッド・ゾーン B にあるパートナー企業から、このホスト上のパブリック IP アドレス (9.2.2.2) へのネットワーク通信を許可するために、下記要件を満たす必要があるものと仮定します。
- 非トラステッド・ゾーン B からこのホストへの IKE トラフィックを許可する。
- 非トラステッド・ゾーン B から、このホストで実行されているセキュア FTP サーバーへの、セキュア FTP トラフィック (TLS/SSL を使用) を許可する。
セキュア FTP には、独自のセキュリティー・メカニズムがあります。IPSec は TLS/SSL と一緒に使用できますが、両方を使用すると処理費用が大きくなります。この例では、IPSec 保護なしのセキュア FTP を許可します。
- 非トラステッド・ゾーン B から、このホストで実行されている Enterprise Extender (EE) サービスへ、EE トラフィックを許可する。その場合、強い暗号化と認証を伴う動的 IPSec トンネルを使用します。
この例では、EE 用として使用される暗号化メカニズムはないので、IPSec がセキュア・サービスを提供します。
- 非トラステッド・ゾーン B からこのホストで実行されている FTP サーバーへの FTP トラフィックを許可する。この場合、強い AH 認証を伴う動的 IPSec トンネルを使用します。
- アウトバウンド EE トラフィックが検出されたときは、EE 用の動的 IPSec トンネルが起動される (オンデマンド活動化)。
- FTP 接続を開始する各リモート・ホストについて、通常の FTP 制御のための動的 IPSec トンネルが活動化される (リモート活動化)。
- リモート・ホストへの各アウトバウンド・データ接続について、通常の FTP データのための動的 IPSec トンネルが活動化される (ローカル活動化)。
- ピアは、RSA シグニチャー方式を使用して互いに相手を認証する。
手順
これらの要件を満たし、パートナー企業モデルを構成するには、以下のステップを実行します。
- 各ゾーンについて、どのようなサービスを許可するかを決定します。
- IKE トラフィック
- 通常の FTP トラフィック
- セキュア FTP トラフィック
- Enterprise Extender トラフィック
- 必要とする各サービスについて、IpService ステートメントを定義します。
- IKE は、メッセージ交換用に、UDP、ポート 500 を使用します。
IpService IKE-local { SourcePortRange 500 DestinationPortRange 500 Protocol UDP Direction bidirectional Routing local SecurityClass 0 } - 通常の FTP トラフィックについては、インバウンド接続は許可し、データを除くアウトバウンド接続要求は許可しません。2 つのサービスが必要です。1 つは制御接続用で、もう 1 つはデータ接続用です。
IpService FTPServer-Control { SourcePortRange 21 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 0 } IpService FTPServer-Data { SourcePortRange 20 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional OutboundConnect Routing local SecurityClass 0 } - セキュア FTP トラフィックについては、インバウンド接続は許可し、データを除くアウトバウンド接続要求は許可しません。2 つのサービスが必要です。1 つは制御接続用で、もう 1 つはデータ接続用です。
IpService SecureFTPServer-Control { SourcePortRange 990 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 0 } IpService SecureFTPServer-Data { SourcePortRange 989 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional OutboundConnect Routing local SecurityClass 0 } - Enterprise Extender トラフィックについては、インバウン
ドとアウトバウンドの両方のトラフィックを許可します。
IpService Enterprise-Extender { SourcePortRange 12000 12004 DestinationPortRange 12000 12004 Protocol UDP Direction bidirectional Routing local SecurityClass 0 }
IP サービスは、簡便性、柔軟性、および構成の再使用可能性を確保するために、グループ化することができます。IP サービス・グループが含まれている IP フィルター規則は、そのグループからのすべてのサービスを含むことができるように拡張されます。以下の IP サービス・グループには、FTPServer および SecureFTPServer を定義する IP サービスが含まれています。
IpServiceGroup FTPServer { IpServiceRef FTPServer-Control IpServiceRef FTPServer-Data } IpServiceGroup SecureFTPServer { IpServiceRef Secure-FTPServer-Control IpServiceRef Secure-FTPServer-Data } - IKE は、メッセージ交換用に、UDP、ポート 500 を使用します。
- 保護するデータ・エンドポイントを判別します。 この例では、ローカル・データ・エンドポイントはサーバーのパブリック・アドレスであり、リモート・データ・エンドポイントはゾーン B 内のサブネットワーク全体です。
Local public IP address: 9.2.2.2 Remote subnet: 9.4.0.0/16 - 各セットのデータ・エンドポイント間に必要なセキュリティーのレベルを判別します。
IKE traffic - permit Secure FTP traffic - permit EE traffic - IPSec encryption and authentication FTP traffic - IPSec authentication - 必要なセキュリティーのレベルを指定する IpGenericFilterAction ステートメントを構成します。 この例の要件によれば、IKE およびセキュア FTP を許可し、EE トラフィックと通常の FTP トラフィックには IPSec 保護を適用する必要があります。
IpGenericFilterAction ステートメントのパラメーターには、permit と deny のほかに ipsec も含まれるという点に注意してください。ロギング要件は指定されていないので、permit と ipsec の 2 つのアクションが必要です。
IpGenericFilterAction permit-nolog { IpFilterAction permit IpFilterLogging no } IpGenericFilterAction ipsec-nolog { IpFilterAction ipsec IpFilterLogging no } - どの 2 つのエンドポイント間にも IPSec が必要な場合は、以下のアクションを実行します。
- 以下のようにして、フェーズ 1 ネゴシエーションのパラメーターを定義する鍵交換ポリシーを構成します。
- フェーズ 1 セキュリティー・アソシエーションについて、必要な保護のタイプと強度を判別します。
フェーズ 1 セキュリティー・アソシエーションは、認証と暗号化の両方を使用する必要があります。フェーズ 2 について強い暗号化が指定されているので、フェーズ 1 にも強い暗号化を使用します。
Authentication, SHA1 algorithm Encryption, 3DES algorithm DHGroup, Diffie-Hellman Group2ヒント: 指定される Diffie-Hellman グループが大きいほど、提供される保護が大きくなります。 - どのタイプのピア認証を使用するかを決定します。
RSA シグニチャーこの例では、リモート・データ・エンドポイントは複数のホストを表しているので、RSA シグニチャーが使用されます。RSA シグニチャー認証は、事前共有秘密鍵認証より高度な柔軟性、スケーラビリティー、およびセキュリティーを提供します。パートナー企業のサブネットには複数のリモート・ピアが存在する可能性があるので、RSA シグニチャーは妥当な選択です。
RSA シグニチャーを使用するには、RACF® 証明書および認証局の情報をセットアップする必要があります。両方の IKE ピアが、それぞれを識別するために、少なくとも 1 つの X.509 デジタル証明書を使用して、鍵リングにアクセスする必要があります。証明書用の IKE デーモンをセットアップする方法については、IP セキュリティーの実行準備のためのステップを参照してください。どのような認証局が認識されるかは、サイトで決定する必要があります。認証局は、外部の商業エンティティーでも、RACF でローカルに定義されているものでも構いません。RACF に認証局をインストールする方法については、「z/OS Security Server RACF セキュリティー管理者のガイド」を参照してください。
この例では、IKEv1 プロトコルが使用されており、IKE デーモンはネイティブ証明書サービスを使用しています。CA4PartnerCompany というラベルを持つ認証局が使用されます。これは、既に RACF データベース内で認証局の 1 つとして定義されているものとします。以下のようにして、この CA4PartnerCompany ラベルを、認識される認証局として iked.conf ファイルに追加します。
SupportedCertAuth CA4PartnerCompanyガイドライン: IKED でネイティブ証明書サービスを使用する場合、証明書の処理をさらに効率化するには、リモート IKE ピアに代わって証明書に署名するために使用される受け入れ可能な各認証局ごとに、SupportedCertAuth をコーディングしてください。 - フェーズ 1 ネゴシエーションのパラメーター (例えば、ピア認証のタイプ、暗号化の強度、およびフェーズ 1 鍵のリフレッシュ頻度など) を定義する KeyExchangeOffer ステートメントを構成します。KeyExchangeOffer ステートメントは再使用可能なので、以下のように記述名を付けてください。
KeyExchangeOffer RSA-SHA1-3DES-DH2 { HowToEncrypt 3DES HowToAuthMsgs SHA1 HowToAuthPeers RsaSignature DHGroup Group2 RefreshLifetimeProposed 480 RefreshLifetimeAccepted 240 1440 RefreshLifesizeProposed none RefreshLifesizeAccepted none } - NAT トラバーサルを許可するかどうかを決定します。
この例では、以下のパラメーターを使用します。
AllowNat No - ネゴシエーション・モードを決定します。フェーズ 1 にはメインモードを使用します。これにより、フェーズ 1 ネゴシエーション時に 2 つの IKE ピアの身元を暗号化して、セキュリティーを強化します。
- フェーズ 1 ネゴシエーションに関する制御情報を定義する KeyExchangeAction ステートメントを構成します。鍵交換アクションでは、フェーズ 1 ネゴシエーションのモードと、KeyExchangeOffer ステートメントに組み込まれているパラメーターが判別されます。複数の KeyExchangeOffer ステートメントが受け入れられますが、必要なのは 1 つだけです。両方のピアが、パラメーターについて同意する必要があります。ここでは、ステップ 6.a.iii で構成した KeyExchangeOffer ステートメントを使用します。
KeyExchangeAction Main-RSA-SHA1-3DES-DH2 { HowToInitiate main HowToRespondIKEv1 main KeyExchangeOfferRef RSA-SHA1-3DES-DH2 } - LocalSecurityEndpoint ステートメントおよび RemoteSecurityEndpoint ステートメントを構成します。この例では、ローカル・セキュリティー・エンドポイントはローカル・ホストです。以下のように、ローカル IKE ピアの身元と IP アドレスが必要です。
LocalSecurityEndpoint Public_IKED { Identity IpAddr 9.2.2.2 Location 9.2.2.2 }同様に、リモート・ホストについても同じ情報が必要です。 RemoteSecurityEndpoint ステートメントで、Identity (身元) と Location (ロケーション) の両方について IP アドレス範囲が指定されるという点に注意してください。 リモート・サブネットワーク内の各ホストごとに RemoteSecurityEndpoint ステートメントを構成することも可能ですが、ホスト間で異なる固有の鍵交換要件がある場合以外は、その必要はありません。 Identity および Location パラメーターにはワイルドカードを使用できます。どの身元タイプにも、身元とロケーションの存在の可能性を考慮したワイルドカードを指定して、類似した身元を持つリモート・ホストのグループを包含することができます。
RemoteSecurityEndpoint ZoneB_IKED { Identity IpAddr 9.4.0.0/16 Location 9.4.0.0/16 CaLabel CA4PartnerCompany }Local_IKED セキュリティー・エンドポイントの Identity パラメーターで IPv4 アドレスを使用する場合は、ローカル IKE デーモンの X.509 デジタル証明書の「Subject Alternative Name」フィールドに、IPv4 アドレスが含まれていることが必要です。 ZoneB_IKED セキュリティー・エンドポイントの Identity パラメーターに IPv4 サブネットを使用する場合は、リモート IKE デーモンの X.509 デジタル証明書の「Subject Alternative Name」フィールドに、そのサブネット (9.4.0.0/16) 内の IPv4 アドレスが入っていなければなりません。
ZoneB_IKED セキュリティー・エンドポイントに CaLabel パラメーターを組み込むと、ラベル CA4PartnerCompany で識別されている認証局が署名した証明書のみをリモート・ホストが使用するように、ローカル・ホストが要求しているという事実が強調されます。
規則: RSA シグニチャー・モード認証の場合は、X.509 デジタル証明書の「Subject Name」フィールドまたは「Subject Alternative Name」フィールドに、セキュリティー・エンドポイントの身元が含まれていなければなりません。RemoteSecurityEndpoint ステートメントでのワイルドカードの指定方法についての詳細は、「z/OS Communications Server: IP 構成解説書」を参照してください。
- 2 つのエンドポイントと鍵交換アクションを含む KeyExchangeRule ステートメントを構成します。
KeyExchangeRule ZoneB_KeyExRule1 { LocalSecurityEndpointRef Public_IKED RemoteSecurityEndpointRef ZoneB_IKED KeyExchangeActionRef Main-RSA-SHA1-3DES-DH2 } - KeyExchangePolicy ステートメントに鍵交換規則を含めます。
KeyExchangePolicy { KeyExchangeRuleRef ZoneB_KeyExRule1 }
- フェーズ 1 セキュリティー・アソシエーションについて、必要な保護のタイプと強度を判別します。
フェーズ 1 セキュリティー・アソシエーションは、認証と暗号化の両方を使用する必要があります。フェーズ 2 について強い暗号化が指定されているので、フェーズ 1 にも強い暗号化を使用します。
- 以下のように、フェーズ 2 ネゴシエーションのパラメーターを定義する IpDynVpnAction ステートメントを構成します。
- フェーズ 2 セキュリティー・アソシエーションについて、必要な IPSec 保護のタイプと強度を判別します。
この例では、各トラフィック・タイプについてそれぞれ固有の要件があります。したがって、以下のように、それぞれのトラフィック・タイプごとに 2 つのタイプの IPSec 保護があります。
EE traffic - strong encryption: ESP, 3DES strong ESP authentication: Hmac SHA1 Normal FTP traffic - strong AH authentication, Hmac SHA1この情報は、最終的には 2 つの IpDataOffer ステートメントに変換されます。
- トンネル・モードまたはトランスポート・モードが必要かどうかを判別します。
トンネル・モードが必要なのは、セキュリティー・アソシエーションのいずれかのエンドポイントがセキュア・ゲートウェイである場合のみです。ホスト対ホスト構成では、選択は任意ですが、一般的にはトランスポート・モードが使用されます。
- フェーズ 2 ネゴシエーションのパラメーターを定義する IpDataOffer ステートメントを構成します。
- FTP の場合の認証済み提示:
IpDataOffer TRAN-AHSHA-NOENCR { HowToEncap Transport HowToEncrypt DoNot HowToAuth AH HMAC_SHA1 RefreshLifetimeProposed 240 RefreshLifetimeAccepted 120 480 RefreshLifesizeProposed none RefreshLifesizeAccepted none } - EE の場合の暗号化および認証済み提示:
IpDataOffer TRAN-ESPSHA-3DES { HowToEncap Transport HowToEncrypt 3DES HowToAuth ESP HMAC_SHA1 RefreshLifetimeProposed 240 RefreshLifetimeAccepted 120 480 RefreshLifesizeProposed none RefreshLifesizeAccepted none }
- FTP の場合の認証済み提示:
- ネゴシエーションの開始をどのピアに許可するかを決定します。
アウトバウンド EE トラフィックが検出されると EE VPN が活動化されるので、ユーザーはネゴシエーションをローカルで開始できることが必要です。FTP 制御接続については、リモート・ホストがセキュリティー・アソシエーションのネゴシエーションを開始するので、ローカルでの開始は不要です。FTP データ接続はローカル・ホストから開始されるので、セキュリティー・アソシエーションを活動化するには、ローカルでの開始が必要です。
- フェーズ 2 ネゴシエーションについて制御情報を定義する IpDynVpnAction ステートメントを構成します。
IpDynVpnAction ステートメントは、ネゴシエーションの開始をどのホストに許可するかを制御するために使用できます。FTP 制御接続については、IPSec VPN をリモート・ピアが開始し、データ接続についてはローカル・ホストが開始することを許可する必要があります。EE は、IKE ネゴシエーションをローカルで開始できることが必要です。
- FTP の場合の認証済み VPN アクション:
IpDynVpnAction FTP-vpnaction { Initiation either InitiateWithPfs group2 AcceptablePfs group2 VpnLife 1440 IpDataOfferRef TRAN-AHSHA-NOENCR } - EE トラフィックの場合の暗号化および認証済み VPN アクション:
IpDynVpnAction EE-vpnaction { Initiation localonly InitiateWithPfs group2 AcceptablePfs group2 VpnLife 1440 IpDataOfferRef TRAN-ESPSHA-3DES }
- FTP の場合の認証済み VPN アクション:
- フェーズ 2 セキュリティー・アソシエーションについて、必要な IPSec 保護のタイプと強度を判別します。
- 以下のように、セキュリティー・アソシエーションをどのように活動化するかを決定します。
- コマンド行からの活動化または自動活動化の場合は、オプションの LocalDynVpnPolicy ステートメントを構成します。
EE および FTP VPN は、コマンド行からの活動化でも自動活動化でもないので、LocalDynVpnPolicy ステートメントは必要ありません。
- セキュリティー・アソシエーションをローカルで活動化し (つまり、オンデマンド、コマンド行、または自動活動化)、セキュリティー・エンドポイントの 1 つがセキュリティー・ゲートウェイとしての役割を果たす (つまりホスト対ホスト・セキュリティー・アソシエーションではない) 場合は、オプションの IpLocalStartAction ステートメントを構成します。
そして、IP フィルター規則に、IpLocalStartAction ステートメントに対する参照を組み込みます。
フェーズ 2 ネゴシエーションを開始可能にする前に、IKE デーモンは、セキュリティー・アソシエーションの対象範囲となっている IP アドレス、ポート、およびプロトコルを認識している必要があります。ほとんどの場合、これらの情報は、フィルター規則からか、またはオンデマンド活動化を開始したパケットから推論することができます。IpLocalStartAction ステートメントは、これらのパラメーターをどこから取得するかを明示的に定義します。これらの情報が、一致するフィルター規則から取り込まれるか、それともパケットから取り込まれるかは、細分性の設定によって決まります。明示的にパケットを指定すれば、各接続要求ごとに新規セキュリティー・アソシエーションの作成を保証できます。
IpLocalStartAction ZoneB-Start-Action { AllowOnDemand yes LocalPortGranularity packet RemotePortGranularity packet ProtocolGranularity packet LocalIpGranularity packet RemoteIpGranularity packet LocalSecurityEndpointRef Public_IKED RemoteSecurityEndpointRef ZoneB_IKED }この例では、packet の指定は必須ではありません。IKE は、フィルター規則にポートの範囲が指定されていることを検出し、デフォルトの rule の代わりにパケット細分性を使用します。ただし、EE および FTP 規則ですべてのポートが指定されている場合は、packet を指定する必要があります。その場合は、単一ポートではなく全ポートを対象として、1 つのセキュリティー・アソシエーションがネゴシエーションされます。混乱を避けるために、ユーザーの意図を指定しておく方が賢明です。
- IpFilterPolicy ステートメントのグローバル PreDecap パラメーターを off に設定するか、または、IPSec トラフィック (AH および ESP) を許可する IpFilterRule ステートメントを作成します。
システムがカプセル化されたトラフィック処理を開始時に、カプセル化されたパケットはフィルター処理の対象となります。暗号化および認証されたパケットは、明示的に許可されている場合を除き、拒否されます。 これを微妙に異なる形で構成するオプションが 2 つあります。最初の 1 つは制限度がより低いもので、どこからの AH および ESP パケットでも許可し、パケットの IPSec ヘッダーの除去が完了するまでは、パケットをフィルター処理対象としません。2 番目の方法では、IPSec カプセル化トラフィックを明示的に許可する IpFilterRule ステートメントを追加します。このオプションでは、暗号化されたトラフィックの送信を誰に許可するかを明確に制御できる、セキュリティー・レイヤーをさらに追加します。この方法では、例えば IPSec パケットの悪意あるアタックの場合に生じるような、IPSec パケットの無用な処理を排除することにより、システム・リソースが保護されます。このソリューションは、すべての IPSec カプセル化トラフィックをフィルターに掛けるために追加の処理リソースを必要とするので、安全度は高まりますが、効率は低下します。
最初のオプションの場合は、以下のように、IpFilterPolicy のメイン・ブロック内に PreDecap off をコーディングします。
IpFilterPolicy { PreDecap off ⋮ }2 番目のオプションの場合は、以下のように、IpFilterPolicy ブロック内 に、AH および ESP トラフィックを明示的に許可するフィルター規則を構成します。
IpFilterRule Allow-IPSec-traffic { IpSourceAddr 9.2.2.2 IpDestAddrSet 9.4.0.0/16 IpService AH-traffic { Protocol AH Direction bidirectional Routing local SecurityClass 0 } IpService ESP-traffic { Protocol ESP Direction bidirectional Routing local SecurityClass 0 } IpGenericFilterRef permit-nolog }ヒント: ほとんどの場合は、追加のセキュリティーが必要と認められない限り、PreDecap off グローバル・オプションを使用して、IPSec パケットが最小限のオーバーヘッドで流れるようにしてください。
- コマンド行からの活動化または自動活動化の場合は、オプションの LocalDynVpnPolicy ステートメントを構成します。
- 以下のようにして、フェーズ 1 ネゴシエーションのパラメーターを定義する鍵交換ポリシーを構成します。
- データ・エンドポイントの各セットについて、IpFilterRule ステートメントを定義します。 データ・エンドポイントを表しているのは、セキュア・ホストとサブネットワーク B です。
IpService ステートメントは、ステップ 2 で定義したものです。
ステップ 6 で作成した IpDynVpnAction ステートメントを、適切な規則を指定して配置します。
IpFilterRule ZoneB-Permitted-traffic { IpSourceAddrRef PublicServerAddress IpDestAddrSetRef ZoneB-subnet IpServiceRef IKE-local IpServiceGroupRef SecureFTPServer IpGenericFilterActionRef permit-nolog } IpFilterRule FTPServer-ZoneB { IpSourceAddr 9.2.2.2 IpDestAddrSet 9.4.0.0/16 IpServiceGroupRef FTPServer IpGenericFilterActionRef ipsec-nolog IpDynVpnAction FTP-vpnaction IpLocalStartActionRef ZoneB-Start-Action } IpFilterRule EE-ZoneB { IpSourceAddr 9.2.2.2 IpDestAddrSet 9.4.0.0/16 IpService { SourcePortRange 12000 12004 DestinationPortRange 12000 12004 Protocol udp Direction bidirectional Routing local SecurityClass 0 } IpGenericFilterActionRef ipsec-nolog IpDynVpnAction EE-vpnaction IpLocalStartActionRef ZoneB-Start-Action }IKE およびセキュア FTP は、どちらも IPSec 保護なしで許可されることが必要なので、どちらについても IpFilterRule ステートメントは不要です。この 2 つのサービスを結合して、1 つの規則にすることができます。
ヒント: 同じデータ・エンドポイントおよび同じセキュリティー要件を共用するサービスは、一緒にまとめて 1 つの IpFilterRule ステートメントに入れることができます。 - IpFilterPolicy ブロックに IpFilterRule ステートメントを含めます。 IKE トラフィックを許可する IpFilterRule ステートメントは、必ずリストの先頭に置くようにしてください。残りの IpFilterRule ステートメントはそれぞれ独立しており、IpFilterPolicy 内でのそれぞれの相対位置には意味はありません。
ヒント: 1 つの特定タイプのトラフィックの発生頻度が最も高いことが判明している場合は、その規則をリストの先頭近くに配置しておけば、フィルター検索の速度が高まります。
- 各ゾーンについて IP フィルター・グループを定義し、それぞれのゾーンに属する IpFilterRule ステートメントを組み込みます。 参照オブジェクトおよびグループの作成は必須条件ではありませんが、これらを作成しておけば、IP セキュリティー・ポリシーが複雑になってきたときの保守が容易になります。
以下に示すのは、すべてのオブジェクトおよびそれぞれの参照も含めて、完全に構成されたポリシーです。
# IpFilterPolicy for secure public server IpFilterPolicy { PreDecap off IpFilterGroupRef ZoneB } KeyExchangePolicy { KeyExchangeRuleRef ZoneB_KeyExRule1 } ###### All reusable statements follow ####### IpFilterGroup ZoneB { IpFilterRuleRef ZoneB-Permitted-traffic IpFilterRuleRef FTPServer-ZoneB #IPSec-protected IpFilterRuleRef EE-ZoneB #IPSec-protected } ###################################### # IpFilterRules # # defines: # # data endpoints # # Allowed services # # Actions (permit, deny, ipsec) # ###################################### IpFilterRule ZoneB-Permitted-traffic { IpSourceAddrRef PublicServerAddress IpDestAddrSetRef ZoneB-subnet IpServiceRef IKE-local IpServiceGroupRef SecureFTPServer IpGenericFilterActionRef permit-nolog } IpFilterRule EE-ZoneB { IpSourceAddrRef PublicServerAddress IpDestAddrSetRef ZoneB-subnet IpServiceRef Enterprise-Extender IpGenericFilterActionRef ipsec-nolog IpDynVpnActionRef EE-vpnaction IpLocalStartActionRef ZoneB-Start-Action } IpFilterRule FTPServer-ZoneB { IpSourceAddrRef PublicServerAddress IpDestAddrSetRef ZoneB-subnet IpServiceGroupRef FTPServer IpGenericFilterActionRef ipsec-nolog IpDynVpnActionRef FTP-vpnaction IpLocalStartActionRef ZoneB-Start-Action } ####################### # Local Start Actions # ####################### IpLocalStartAction ZoneB-Start-Action { AllowOnDemand yes LocalPortGranularity packet RemotePortGranularity packet ProtocolGranularity packet LocalIpGranularity packet RemoteIpGranularity packet LocalSecurityEndpointRef Public_IKED RemoteSecurityEndpointRef ZoneB_IKED } #################### # IpService groups # #################### IpServiceGroup FTPServer { IpServiceRef FTPServer-Control IpServiceRef FTPServer-Data } IpServiceGroup SecureFTPServer { IpServiceRef SecureFTPServer-Control IpServiceRef SecureFTPServer-Data } ################################## # Services provided by this host # ################################## IpService IKE-local { SourcePortRange 500 DestinationPortRange 500 Protocol UDP Direction bidirectional Routing local SecurityClass 0 } IpService SecureFTPServer-Control { SourcePortRange 990 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 0 } IpService SecureFTPServer-Data { SourcePortRange 989 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional OutboundConnect Routing local SecurityClass 0 } IpService Enterprise-Extender { SourcePortRange 12000 12004 DestinationPortRange 12000 12004 Protocol UDP Direction bidirectional Routing local SecurityClass 0 } IpService FTPServer-Control { SourcePortRange 21 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 0 } IpService FTPServer-Data { SourcePortRange 20 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional OutboundConnect Routing local SecurityClass 0 } ###################### # Security Endpoints # ###################### LocalSecurityEndpoint Public_IKED { Identity IpAddr 9.2.2.2 Location 9.2.2.2 } RemoteSecurityEndpoint ZoneB_IKED { Identity IpAddr 9.4.0.0/16 Location 9.4.0.0/16 CaLabel CA4PartnerCompany } ########################## # Generic filter actions # ########################## IpGenericFilterAction permit-nolog { IpFilterAction permit IpFilterLogging no } IpGenericFilterAction ipsec-nolog { IpFilterAction ipsec IpFilterLogging no } ################################## # Key Exchange offers # # defines: # # Authentication type # # Encryption type # # Peer authentication method # # Refresh limits # ################################## KeyExchangeOffer RSA-SHA1-3DES-DH2 { HowToEncrypt 3DES HowToAuthMsgs SHA1 HowToAuthPeers RsaSignature DHGroup Group2 RefreshLifetimeProposed 480 RefreshLifetimeAccepted 240 1440 RefreshLifesizeProposed none RefreshLifesizeAccepted none } ################################## # Key Exchange Actions # # defines: # # Negotiation mode # # List of Key exchange offers # ################################## KeyExchangeAction Main-RSA-SHA1-3DES-DH2 { HowToInitiate main HowToRespondIKEv1 main KeyExchangeOfferRef RSA-SHA1-3DES-DH2 } ###################################### # KeyExchangeRules # # defines: # # A pair of security endpoints # # permitted in IKE negotiations # ###################################### KeyExchangeRule ZoneB_KeyExRule1 { LocalSecurityEndpointRef Public_IKED RemoteSecurityEndpointRef ZoneB_IKED KeyExchangeActionRef Main-RSA-SHA1-3DES-DH2 } ############################ # Data Offers # # defines: # # Encapsulation mode # # Authentication type # # Encryption type # # Refresh limits # ############################ ### Authenticated offer ### IpDataOffer TRAN-AHSHA-NOENCR { HowToEncap Transport HowToEncrypt DoNot HowToAuth AH HMAC_SHA1 RefreshLifetimeProposed 240 RefreshLifetimeAccepted 120 480 RefreshLifesizeProposed none RefreshLifesizeAccepted none } ### Encrypted offer ### IpDataOffer TRAN-ESPSHA-3DES { HowToEncap Transport HowToEncrypt 3DES HowToAuth DoNot RefreshLifetimeProposed 240 RefreshLifetimeAccepted 120 480 RefreshLifesizeProposed none RefreshLifesizeAccepted none } ############################## # Dynamic VPN Actions # # defines: # # Initiation role # # Pfs group # # Lifetime of connection # # List of Data offers # ############################## IpDynVpnAction FTP-vpnaction { Initiation either InitiateWithPfs group2 AcceptablePfs group2 VpnLife 1440 IpDataOfferRef TRAN-AHSHA-NOENCR } IpDynVpnAction EE-vpnaction { Initiation localonly InitiateWithPfs group2 AcceptablePfs group2 VpnLife 1440 IpDataOfferRef TRAN-ESPSHA-3DES } ################ # IP addresses # ################ IpAddr PublicServerAddress { Addr 9.2.2.2 } IpAddrSet ZoneB-subnet { Prefix 9.4.0.0/16 } - 構成したすべてのステートメントをスタック固有 IP セキュリティー構成ファイルに含めます。