VMware Hands-on Labs - HOL-1724-SDC-1-JA


ラボの概要 - HOL-1724-SDC-1 - Check Point vSECとVMware NSX: 高度なSDDCセキュリティ

Lab Guidance


注: このラボのすべてのモジュール実施するには、通常90分以上かかります。制限時間内にモジュールを2~3個完了することを目安としてください。各モジュールはそれぞれ独立した内容になっているため、どのモジュールから開始してもかまいません。ただし、モジュール内では冒頭から順番に作業を進めるようにしてください。各モジュールには、目次から直接ジャンプできます。

目次へのアクセスには、ラボ・マニュアルの右上にあるボタンを使用します。

重要: ラボを初めて開始する際は、まずメイン・コンソールの [Lab Status] の表示を確認してください。[Lab Status] が [READY] になっていたら、ラボを開始してください。[FAILED] の場合はいったんラボを終了し、新しいラボを開始してください。

画面解像度についての注意: メイン・コンソールの画面は、1024 x 768の解像度に最適化されています。VMware Learning Platformでは、Webブラウザ内の利用可能な面積に合わせてデスクトップのサイズが自動調整されますが、受講者がコンソール画面のサイズを調整すると、それに合わせて再度調整されます。

要約: Check Point vSECとVMware NSXの統合により、SDDC環境において、互いを補完する高度なセキュリティ機能が実現します。NSXの分散ファイアウォール(DFW)は、L2-L4の基本的な分散ファイアウォール・サービスを提供します。これに対し、Check Point vSECは、L5-L7に対応した高度なセキュリティ・サービス(IPS、アプリケーション制御およびURLフィルタリング、アイデンティティ認識、アンチウイルス、アンチボット、脅威エミュレーション)を提供します。またCheck Point Security Managementを使用すれば、組織で運用するチェック・ポイントの物理ゲートウェイと仮想アプライアンスの両方をシームレスに管理可能となります。チェック・ポイントは、SDDCを含むあらゆるIT環境の保護に対応しています。SDDCにおいて「Security as a Workload」(ワークロードとしてのセキュリティ)を実現するCheck Point vSECにより、頻繁に実施されるアプリケーションの導入およびプロビジョニングに合わせて、高度なセキュリティ機能をシームレスに展開することが可能となります。

各モジュールの概要:

ラボの責任者:

このラボ・マニュアルは、次のハンズオン・ラボ・ドキュメント・サイトからダウンロードできます。

http://docs.hol.vmware.com

このラボは、英語以外の言語で提供されている場合もあります。言語設定を変更し、各国語版のマニュアルを使用する手順については、次のドキュメントをご覧ください。

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

メイン・コンソールの場所

 

  1. 図の中で、赤い大きな枠で囲まれた部分がメイン・コンソールです。ラボ・マニュアルは、メイン・コンソールの右側のタブに表示されます。
  2. 一部のラボでは、画面左上のタブに別のコンソールが表示されます。必要に応じて、別のコンソールを開くように指示されます。
  3. ラボを開始すると、90分間のタイマーがスタートします。ラボを途中で保存することはできません。すべての作業をラボ・セッション中に終える必要があります。ただし、[EXTEND] をクリックするとラボの時間を延長できます。VMwareのイベントでは、時間を2回(30分間)延長でき、[EXTEND] をクリックするたびに15分間延長されます。VMwareのイベント以外では、最長で9時間30分延長でき、[EXTEND] をクリックするたびに1時間延長されます。

 

 

Windowsのアクティブ化を求める透かし文字

 

ラボを開始したとき、Windowsがアクティブ化されていないことを示す透かし文字がデスクトップに表示される場合があります。

仮想化の最大のメリットの1つは、仮想マシン(VM)をプラットフォーム間で移動して実行できる点です。ハンズオン・ラボでは、このメリットを活用して、複数のデータセンターからラボを実施できるようにしています。しかし、各データセンターで使用しているプロセッサが同一であるとは限らず、その場合はインターネット経由でのアクティブ化チェックが必要となります。

VMwareおよびハンズオン・ラボでは、Microsoftのライセンス要件に従ってWindowsを運用していますが、このラボ・マシンはスタンドアロン型であり、Windowsによるアクティブ化の検証に必要となる完全なインターネット接続を備えていません。

そのため、アクティブ化の自動検証プロセスが失敗し、この透かし文字が表示されます。

これはあくまでも表示上の問題であり、ラボの実施に支障はありません。

 

 

データを入力する複数の方法

 

このモジュールでは、メイン・コンソールにテキストを入力します。テキストを直接タイプする方法以外にも、複雑なデータの入力が容易になる2つの入力方法が用意されています。

 

 

ラボ・マニュアルの文字列をコンソールのアクティブ・ウィンドウにドラッグ

ラボ・マニュアルに記載されたテキストやコマンドライン・インタフェース(CLI)のコマンドを選択し、メイン・コンソールのアクティブ・ウィンドウにドラッグすると、そのテキストやコマンドを対象のウィンドウにペーストできます。

 

 

オンスクリーンキーボードの利用

 

メイン・コンソールでは、オンスクリーンキーボードを使用することもできます。

  1. Windowsのクイック起動ツールバーにあるキーボードのアイコンをクリックします。

 

 

アクティブなコンソール・ウィンドウを1回クリック

 

ここでは、オンライン・キーボードを使用して、電子メール・アドレスで使用される「@」記号を入力してみます。「@」記号を入力するには、Shiftキーを押しながら2キーを押します(USキーボード配列の場合)。

  1. アクティブなコンソール・ウィンドウを1回クリックします。
  2. Shiftキーをクリックします。

 

 

@キーをクリック

 

  1. @キーをクリックします。
  2. 「@」記号がアクティブなコンソール・ウィンドウに入力されます。

 

 

画面右下を確認

 

準備作業がすべて完了し、ラボを開始する用意が整ったかどうかを確認します。「Ready」以外の文字列が表示されている場合は、しばらくお待ちください。5分経過しても「Ready」の文字が表示されない場合は、お問い合わせください。

 

Control Center ブラウザ言語設定(日本語)

Firefox ブラウザ言語設定 (日本語表示)


vSphere Web Clientはブラウザベースです。日本語表示するためには、ブラウザの言語設定を日本語に設定します。

なお、vSphere Web Client 以外の一部ツールでは英語表記となります。これはハンズオンラボ環境特有のものです。


 

Firefoxの起動

 

Firefoxアイコンをクリックし、 起動します。

 

 

Firefoxブラウザの日本語化

 

1. ウィンドウ右上のメニューを開きます。

2. [Options]  をクリックします。

 

 

Firefoxブラウザの日本語化

 

左側メニューから [Content] を選択します。

 

 

Firefoxブラウザの日本語化

 

[Languages] の [Choose...] をクリックします。

 

 

Firefoxブラウザの日本語化

 

[Select a language to add...] をクリックします。

 

 

Firefoxブラウザの日本語化

 

1. プルダウンから [Japanese [ja] ] を選択します。

2. [Add] をクリックします。

3. [OK] をクリックします。

4. Firefox を再起動します。

 

Google Chrome ブラウザ言語設定(日本語表示)


vSphere Web Client はブラウザベースです。日本語表示にする為には、ブラウザの言語設定を日本語に設定します。

なお、vSphere Web Client 以外の一部ツールでは英語表記となります。これはハンズオンラボ環境特有のものです。


 

Google Chrome の起動

 

Google Chrome を起動します。

 

 

Google Chrome のメニューを開く

 

ブラウザウィンドウ右上のメニューを開きます。

 

 

Google Chrome の設定画面を開く

 

[Settings] をクリックします。

 

 

Google Chrome の詳細設定を表示

 

1. 画面を下へスクロールします。

2. [Show advanced settings...] をクリックします。

 

 

Google Chrome の言語と入力の設定

 

画面を下へスクロールし、[Language and input setting...] をクリックします。

 

 

Google Chrome の言語と入力の設定

 

[Add] をクリックします。

 

 

Google Chrome の言語と入力の設定

 

1. プルダウンから [Japanese - 日本語] を選択します。

2. [OK] をクリックします。

 

 

Google Chrome の言語と入力の設定

 

1. 左側 [Languages] 内の [Japanese] を一番上までドラッグで移動させます。

2. [Done] をクリックします。

3. Google Chrome ブラウザを再起動します。

 

モジュール1 - Check Point vSECの紹介、設定、トラフィックのリダイレクト(30分)

はじめに


重要:ラボを初めて開始する際は、まずメイン・コンソールの [Lab Status] の表示を確認してください。[Lab Status] [READY] になっていたら、ラボを開始してください。[FAILED] の場合はいったんラボを終了し、新しいラボを開始してください。

このモジュールで学習する内容は次のとおりです。

このモジュールでは、Check Point vSECとVMware NSX ManagerおよびvCenterとの統合で提供される機能について学習します。Check Point vSECの各コンポーネントおよびvSECの管理に関するスキル、vSECの統合コンポーネントを確認するためのNSX Managerの設定画面、トラフィックがvSECにリダイレクトされる仕組みを学びます。

このモジュールを終えると、vSEC、vSECの各コンポーネント、VMware vCenterおよびNSX Managerとの統合について十分な知識を得て、トラフィックがvSECにリダイレクトされる仕組みを理解できます。

HOLラボに関する注: このHOLチェック・ポイント・パートナー・ラボ環境は、すでにセットアップが完了しており、次の設定が行われています。

  1. VMware vCenter ServerおよびNSX Managerの導入
  2. vSphereデータセンター、クラスタ、およびデータセンター・オブジェクトの設定
  3. クラスタを構成するESXiホストでのエージェントVMの設定
  4. vCenterのランタイム設定
  5. NSX Managerの適切なクラスタへのインストール
  6. vSECゲートウェイで使用するIPアドレス・プールの準備
  7. Check Point R77.30 Security Managementサーバの導入
  8. vSECセキュリティ・ゲートウェイ・サービスの設定とvSECコントローラのvCenterおよびNSX Managerへの登録
  9. vSECクラスタ・オブジェクトの定義
  10. vSECゲートウェイ・インスタンスのクラスタ・メンバーとしての割り当て
  11. ベスト・プラクティス: 各VMへのVMwareツールのインストール
  12. ベスト・プラクティス: ポート・グループへのSpoof Guardの適用

周辺コンポーネント:


Check Point vSECを構成するコンポーネントの概要


このレッスンでは、Check Point vSECを構成するコンポーネントを見ていきます。

注: このラボ用のセットアップはすでに完了しています。


 

Check Point vSECの設定メニュー

 

Check Point vSECと物理的なゲートウェイとの違いは何でしょうか。Check Point vSECとVMware NSXの統合ソリューションは、主に次の2つのコンポーネントで構成されています。まず1つはvSECコントローラです。vSECコントローラは、Check Point Security Managementサーバのアドオンであり、NSX ManagerとのSDN統合のための機能を提供します。そしてもう1つは、トラフィックを検査して仮想NICレベルでセキュリティ・ポリシーを実施するCheck Point vSECゲートウェイ(セキュリティ・ゲートウェイ・サービス)です。

vSECコントローラをインストールすると、新たにvSECの設定メニューが追加されます。このメニューを確認するため、SSHでCheck Point R77.30 Security Managementサーバに接続してみましょう。

タスク・バーからPuTTYを起動します。[Saved Sessions] で、[cpsmsvsec] >> [Load] >> [Open] の順にクリックします。

 

 

Security ManagementサーバのCLIへのログイン

 

パスワードの入力を求められたら、「VMware1!」と入力します。

 

 

「vsec config」と入力

 

Gaiaのコマンドラインが表示されます。

gw-01356b >プロンプトで次のように入力し、Enterキーを押します。

vsec config  

vSEC Service Managerメニューが表示されます。vSEC Service ManagerはvSECコントローラの別称であり、両者は同じツールを指している点に注意してください。

初期設定では、グローバル設定を定義します。

ラボ用のグローバル設定はすでに完了しているため、ここでは、定義済みの接続、登録済みのサービス、グローバル設定を確認してみます。

 

 

vSEC Service Managerメニュー >> NSX Managerに接続

 

vSEC Service Managerメニューのオプション6を選択すると、vSECコントローラからNSX Managerへの接続を表示できます。

[Selected option:] で「6」と入力し、Enterキーを押します。

Smart Dashboardで設定されているNSX Managerのリストが表示されます。

リストの冒頭に、nsxmgr-01a.corp.localという名前のNSX Managerが表示されるはずです。

「1」と入力し、Enterキーを押します。「Checking connection to NSX...」(NSXへの接続を確認しています)というメッセージが表示されます。

vSECコントローラとNSX Manager間の接続が確立されると、「Connection from the vSEC management to NSX nsxmgr-01a.corp.local established」(vSECコントローラからNSX Managerのnsxmgr-01a.corp.localへの接続が確立されました)というメッセージが表示されます。

 

 

vSEC Service Managerメニュー >> サービスの表示

 

先ほどのメッセージの後に、再びvSEC Service Managerメニューの選択画面が表示されているはずです。

[Selected option:] で「4」と入力し、Enterキーを押します。

先ほどと同じく、Smart Dashboardで設定されているNSX Managerのリストが表示されます。

リストの冒頭に、nsxmgr-01a.corp.localという名前のNSX Managerが表示されます。

「1」と入力し、Enterキーを押します。

すでに登録されているサービスのリストが表示されます。「Service Name: vsecsvm」と「Failure Policy: Fail-Open」という文字列が表示されるはずです。

この文字列は、vsecsvmという名前のvSECゲートウェイ・サービスが登録されており、失敗ポリシーがフェイル・オープンに設定されていることを示しています。

注: この文字列に続いて、再びvSEC Service Managerメニューの選択画面が表示されます。

 

 

vSEC Service Managerメニュー >> グローバル設定

 

次に、グローバル設定を確認してみましょう。ラボ用のグローバル設定はすでに完了しているため、ここでは確認するだけです。

注: 実際の初期設定では、NSX ManagerとのSecure Internal Communications(SIC)接続を確立するためのパラメータ、サービス・ポート、NSX Managerに登録するサービスの名前、後でNSX Managerに展開するCheck Point vSECゲートウェイのOVFテンプレートのURLを指定することになります。

繰り返しになりますが、ここでは設定を確認するだけです。

vSEC Service Managerメニューの [Selected option:] で「1」と入力し、Enterキーを押します。

Service ManagerのIPアドレスは192.168.110.112であることが確認できます。これは、vSECコントローラのIPアドレスです。前述したように、vSECコントローラは、SDN統合のための機能を提供する、Check Point Security Managementサーバのアドオンです。このvSECコントローラは、Service Managerポート8443経由でNSX Managerと通信します。また、Check Point vSECセキュリティ・ゲートウェイ・サービスのVMのOVFテンプレートが置かれたURLも確認できます。

グローバル設定が適切に定義されている場合、初期展開では次の処理が行われます。

  1. vSECコントローラがポート8443でNSX Managerに接続する
  2. vSECコントローラがNSX Managerの認証を受ける
  3. vSECコントローラとNSX Managerが証明書を交換する
  4. vSECコントローラとNSX Managerの間でSICが確立される
  5. 登録されたサービス名がvSEC Service Managerメニューのオプション3 [Register Service] に表示される

登録済みのサービスは、NSX Managerの [Service Deployments] タブに表示されます。このタブについては、本モジュールのレッスン2で確認します。

 

 

vSEC Service Managerメニューの終了

 

ここまで、vSEC Service Managerメニューについて見てきました。続いて、Check Point SmartDashboardとSmartLogのGUIを確認していきます。

まず、vSEC Service Managerメニューを終了します。

[Selected option:] で「4」と入力し、Enterキーを押します。続いて「8」と入力し、Enterキーを押すと、メニューが終了して Gaiaのコマンド・プロンプトに戻ります。

gw-01356b >プロンプトで「exit」と入力して、Security Managementサーバからログアウトします。

PuTTYが終了します。

 

 

Check Point R77.30 SmartDashboard

 

メイン・コンソールのデスクトップでSmartDashboard R77.30のアイコンをダブルクリックして、Check Point SmartDashboardを起動します。SmartDashboardは、組織全体のセキュリティ・ポリシーや物理/仮想セキュリティ・ゲートウェイを管理するためのGUIです。

 

 

SmartDashboardの認証情報の入力

 

SmartDashboardの認証情報を入力するウィンドウが表示されます。ユーザ名とIPアドレスは自動入力されています。パスワードとして「VMware1!」と入力し、[Login] ボタンをクリックします。

 

 

Check Point R77.30 SmartDashboardのSDDCセキュリティ・ポリシー

 

SmartDashboardのセキュリティ・ポリシー・ビューが表示されます。

注: ここでは、SDDC用に定義された次のファイアウォール・ルールが表示されます。

左側のパネルの [Network Objects] には、次のSDDCオブジェクトが表示されます。

続いて、SmartLogの画面を見てみましょう。

 

 

Check Point R77.30 SmartLog

 

Check Point SmartDashboardで次の手順を実行します。

  1. メニュー・バーにある [SmartConsole] ドロップダウン・リストをクリックします。
  2. [SmartLog] をクリックしてCheck Point SmartLogを起動します。

SmartLogは、セキュリティ・ログをリアルタイムで確認するためのGUIコンソールです。

 

 

SmartLogの表示

 

SmartLogのビューが表示されます。

 

 

[Search Query] フィールドの条件変更

 

[Search Query] フィールドをクリックし、ドロップダウン・リストで [action:Accept] を選択してから、更新アイコン(右向き矢印のアイコン)をクリックします。指定した検索条件が適用され、許可されたトラフィックの最新のログが表示されます。

 

 

自動更新アイコンと更新アイコン

 

[Query Search] フィールドの右側にある自動更新アイコンをクリックします。「A」という文字と右向き矢印が描かれたアイコンです(右向き矢印だけのアイコンは更新アイコンです)。どちらのアイコンも、SmartLogに新たな検索条件を適用するために使用できます。

 

 

許可されたトラフィックの表示

 

許可されたトラフィックの最新のログがリアルタイムで表示されます。

 

 

ログの詳細表示

 

許可されたトラフィックのログ・エントリをダブルクリックします。すると、そのログ・エントリの詳細情報が表示されます。

この画面で、トラフィックの内容、例えば、関連するサービスやそのトラフィックを許可したルールなどを確認できます。

ヒント: この段階では、まだHOLを開始したばかりであり、実質的なトラフィックは発生していません。ここで表示されているトラフィックは、メイン・コンソールとCheck Point R77.30 Security Managementサーバ間で発生した通信です。

この後で確認するトラフィックには、データセンター・オブジェクトやセキュリティ・グループの名前が含まれています。vSECとNSXの統合ソリューションでは、vCenterのデータセンター・オブジェクトとNSX Managerのセキュリティ・グループの情報をチェック・ポイントのセキュリティ・ポリシーに取り込むことができます。これらのオブジェクトは、動的データセンター・オブジェクトと呼ばれ、その情報はログに記録されます。

SmartLogを活用すれば、組織内でのセキュリティ・ポリシーの実施状況を詳細なログで確認できます。

このトピックについては、モジュール2で詳しく学習します。

SmartLogは後でまた使用しますので、起動したままウィンドウを最小化しておいてください。

 

NSX ManagerおよびvCenterとCheck Point vSECとの統合の確認


このレッスンでは、NSX ManagerとvCenterの設定画面を開き、Check Point vSECを構成するコンポーネントの設定場所を確認します。NSX ManagerおよびvCenterに関する知識があると、スムーズに作業を進めることができます。このレッスンの目的は、VMwareの各種統合コンポーネントについての理解を深めることです。


 

NSX Manager - ホストの準備

 

注: このラボでは、サイトA用とサイトB用に2つのNSX Managerを用意していますが、ここで使用するのはサイトAと同サイト用のNSX Manager 192.168.110.15のみとなります。

[NSX Component Installation on Hosts] 画面が表示されます。[Host Preparation] タブには、NSX Managerが展開されているデータセンター・クラスタとホストが表示されます。

このラボでは、クラスタを1つ(RegionA01-COMP01)と、ESXiホストを2台(esx-01a.corp.localおよびesx-02a.corp.local)構成しています。

Check Point vSECは、NSX Managerに合わせて展開されています。データセンター・クラスタに展開されたNSX Managerは、このクラスタ向けにネットワーク・サービスとセキュリティ拡張サービス(ネットワーク・ハイパーバイザと分散ファイアウォール)を提供します。Check Point vSECゲートウェイ・サービスは、NSX Managerと同じクラスタに展開されており、このクラスタ上のすべてのホストおよびアプリケーションVMを保護します。

 

 

NSX Manager - サービスの展開

 

同じ画面で [Service Deployments] タブをクリックします。

[Network & Security Service Deployments] 画面が表示されます。

Check Point vSEC Service Managerメニューで目にしたvsecsvmサービスの名前をここで確認できます。

この画面では、vSECサービスが正しくRegionA01-COMP01クラスタに展開されており、同サービスが起動し、同サービスのVMで使用するVMwareポート・グループとIPアドレス・プールが定義されていることを確認できます。

これで、必要なコンポーネントがすべて設定されていることを確認できました。

 

 

NSX Manager

 

次に、NSX Managerの設定画面に移動し、先ほど見たIPプールの設定を確認します。

このIPプールの目的は何か、お分かりでしょうか。

このIPプールは、自動設定プロセスでのvSECゲートウェイ・サービスの展開に使用されます。

vSECサービスがNSX Managerから展開される際、vSECゲートウェイのVMが各クラスタ・メンバーに展開されます。このVMの展開は、完全に自動で実施されます。インスタンスの展開時には、クラスタ・メンバーごとに1つのインスタンスが★割り当てられます★。

では、この自動展開プロセスでは、どのような処理が行われているのでしょうか。vSECゲートウェイ・サービスのVMは、前述したOVFテンプレートから展開されます。展開されたインスタンスが起動し、NSX ManagerのIPプールからIPアドレスを取得して、自動設定した後、vSECコントローラをインストール済みのSecurity Managementサーバに接続します。そして、クラスタ・オブジェクトとそれぞれのインスタンス・オブジェクトをトポロジに沿って構築し、Security Managementサーバから初期セキュリティ・ポリシーを取得します。

vSECゲートウェイ・サービスのVMを自動展開する際に使用されるIPプールがどこで定義されているのかを見てみましょう。左側のパネルで [Network & Security Inventory] を展開し、[NSX Managers] をクリックして、[192.168.110.15] をクリックします。

 

 

NSX Manager

 

NSX Manager 192.168.110.15の画面で [Manage] タブをクリックし、[Grouping Objects] >> [IP Pools] の順にクリックします。

ここに、vSECゲートウェイ・サービスのVMに使用するIPプールが定義されています。

このモジュールのレッスン3では、Check Point vSECゲートウェイ・サービスへのトラフィックのリダイレクトを設定するためのNSX Managerの画面と、Check Point vSECとVMware NSXの分散ファイアウォールが連携する仕組みについて学習します。

 

vSECへのトラフィックのリダイレクト


このレッスンでは、トラフィックをCheck Point vSECにリダイレクトする基本的な仕組みについて学習します。

トラフィックをリダイレクトするためには、まずvSECゲートウェイ・サービスをNSX Managerに登録し、NSXに展開する必要があります。

ただし、このモジュール用の作業はすでに完了しています。

vSECゲートウェイ・サービスが登録および展開されているかどうかを確認する方法については、前回のレッスンで学習しました。


 

NSXサービスの定義

 

トラフィックのリダイレクトについて理解するためには、各統合コンポーネントの関係を把握しておく必要があります。

そのため、このレッスンではまず、[Service Definitions] 画面と [Service Managers] 画面を見ていきます。両画面では、Check Point vSECのサービス仮想マシン(SVM)とCheck Point vSEC Service Managerを確認できます。このvSEC Service Managerが、vSECコントローラ上で実行されているvSEC Service Managerとなります。

メイン・コンソールのChromeブラウザでvSphere Web Clientを開き、[Networking & Security] をクリックします。左側のパネルで [Service Definitions] を展開して [Services] をクリックします。

vsecsvmサービスが表示され、そのバージョンがR77.30であることを確認できます。また、ファイアウォール、IPS、ホスト・ベースのvNICを搭載しており、CP_vSEC_ServiceManager_201293845というService Managerに関連付けられていることが分かります。

 

 

NSX Service Manager

 

[Security Manager] タブをクリックして、既存のService Managerを表示します。

CP_vSEC_ServiceManager_201293845という名前のCheck Point Service Managerが表示されます。

 

 

CP_vSEC_ServiceManager_201293845の選択

 

Check Point Service ManagerのCP_vSEC_ServiceManager_201293845をクリックして選択状態にします。

鉛筆アイコンをクリックしてCheck Point Service Managerの編集画面を表示します。

このラボでは、vSECの設定はすでに完了しています。

編集画面が表示されても、設定は変更しないでください。

 

 

[Edit Service Manager] ウィンドウ

 

鉛筆アイコンをクリックすると、[Edit Service Manager] ウィンドウが表示されます。

このCheck Point Service Managerは、vSECコントローラ上で実行されていることが分かります。

この画面では何も変更しないでください。

[Cancel] をクリックしてウィンドウを閉じます。

 

 

Service Composer経由でのvSECの利用

 

では、トラフィックはどのようにリダイレクトされるのでしょうか。

Check Point vSECとNSX Managerを統合すると、有効性、効率性、合理性に優れた相互補完的なセキュリティ・サービスがSDDC環境で利用可能になります。そのメリットの大きさを正しく理解するためには、NSXの分散ファイアウォールからCheck Point vSECゲートウェイ・サービスにトラフィックがどのようにリダイレクトされるかを理解しなければなりません。

トラフィックのリダイレクトには、次に紹介するVMware NSXの3つのコンポーネントが関係します。

NSX Service Composerは、一連のvCenterオブジェクトでvSECゲートウェイ・サービスを利用するためのVMwareコンポーネントです。NSXセキュリティ・グループは、このNSX Service Composerで作成、管理します。

NSXセキュリティ・グループは、クラスタやVM、vNIC、論理スイッチなどのvCenterオブジェクトの集まりです。

最後のコンポーネントは、分散ファイアウォール(DFW)ポリシーのルールです。

DFWポリシーは、vSECにリダイレクトされるセキュリティ・グループにマップされます。トラフィックのリダイレクト・ルールは、vSECのサービス・プロファイル上に作成します。

では、NSX Service Composerの設定画面を見ていきましょう。

先ほどと同じvSphere Web Clientの [Networking & Security] から、左側のパネルにある [Service Composer] を展開します。

[Security Groups] タブをクリックし、既存のセキュリティ・グループを表示します。

 

 

VMsセキュリティ・グループに関連付けられたVM

 

VMsというセキュリティ・グループをクリックし、その行を選択状態にします。

[Virtual Machines] という列のハイパーリンクをクリックします。

この列には、「3」という数字が表示されています。これは、3つのVM(web-01.corp.local、app-01.corp.local、db-01a.corp.local)がVMsセキュリティ・グループに関連付けられていることを示しています。この後のモジュールでは、この3つのVMを使用してトラフィックを発生させ、セキュリティ・ポリシーの実施結果をSmartLogで確認します。

 

 

VMsセキュリティ・グループに関連付けられたネットワーク観察ルール(Network Introspection Rules)

 

引き続き、VMsセキュリティ・グループについて見ていきましょう。[Network Introspection Services] という列のハイパーリンクをクリックします。この列には、「2」という数字が表示されています。これは、2つのネットワーク観察ルールがVMsセキュリティ・グループに関連付けられていることを示しています。

 

 

VMsセキュリティ・グループに関連付けられたセキュリティ・ポリシー

 

VMsセキュリティ・グループの確認を続けます。今度は、[Security Policy] という列のハイパーリンクをクリックします。この列には、「1」という数字が表示されています。これは、1つのセキュリティ・ポリシーがVMsセキュリティ・グループに関連付けられていることを示しています。

 

 

VMsセキュリティ・グループのセキュリティ・ポリシー設定の確認

 

[Security Policy] という文字列にマウス・カーソルを合わせます。この文字列はハイパーリンクになっていますので、そのままクリックします。

リンクをクリックすると、[Security Policy - Manage Security Policy] ウィンドウが表示されます。

左側のパネルの [Network Introspection Services] をクリックします。

 

 

VMsセキュリティ・グループのセキュリティ・ポリシー設定の詳細確認

 

この画面には、ルール1とルール2が表示されています。

NSXセキュリティ・ポリシーでは、ルールはペアで作成することになっています。

1つは、該当のセキュリティ・グループを送信元とするトラフィックに適用されるルールです。

もう1つは、該当のセキュリティ・グループを送信先とするトラフィックに適用されるルールです。

ルール1を1回クリックしてから、鉛筆アイコンをクリックします。[Edit Network Introspection Service] ウィンドウが表示されます。

設定に目を向けると、[Redirect to service] で、リダイレクト先のサービスがvsecsvmに設定されていることが分かります。vsecsvmは、vSEC Service Managerメニューで確認した登録済みのサービスです。

何も変更せず、[Cancel] クリックしてウィンドウを閉じます。

 

 

トラフィックのリダイレクトのまとめ

vSECとNSXの統合ソリューションでは、セキュリティ・ポリシーは、DFWのファイアウォール・ルールと、vSECゲートウェイ・サービスが提供する★ネットワーク観察サービス(Network Introspection Service)★で構成されることになります。

VMsセキュリティ・グループに関連付けられたVMからのトラフィック・フローは、関連するネットワーク観察ルールによって、登録済みサービスのvsecsvm(vSECゲートウェイ・サービス)にリダイレクトされます。vSECゲートウェイ・サービスはこのトラフィックを検査し、Check Point Security Managementサーバで定義されたセキュリティ・ポリシーを実施します。

注: トラフィックのリダイレクト先であるvSECゲートウェイにポリシーが設定されていない場合、トラフィックは、vSECの管理者が定義した失敗ポリシーの設定に従って処理されます。

注: 初期導入の際、NSXの分散ファイアウォール(DFW)のデフォルト・ルール・アクションがブロックに設定されている場合は、トラフィックのリダイレクトを許可するためのルールを追加する必要があります。

 

まとめ


このモジュールでは、Check Point vSEC、vSECの各コンポーネント、VMware vCenterおよびNSX Managerとの統合についての知識を得ると共に、トラフィックがvSECにリダイレクトされる仕組みを学習しました。

SDDCのセキュリティ専門家を目指し、引き続き頑張っていきましょう。

次のモジュールにお進みください。


 

モジュール1の終了

 

以上で、モジュール1のレッスンはすべて終了しました。

Check Point vSECによるSDDCの保護について、さらに詳しく知りたい場合は、次のいずれかの方法で追加資料をご覧ください。

ご興味のある次のいずれかのモジュールにお進みください。

 

モジュール2 - vCenterおよびNSXオブジェクトによる動的なポリシー適用(30分)

はじめに


重要:ラボを初めて開始する際は、まずメイン・コンソールの [Lab Status] の表示を確認してください。[Lab Status] [READY] になっていたら、ラボを開始してください。[FAILED] の場合はいったんラボを終了し、新しいラボを開始してください。

このモジュールでは、動的セキュリティ・ポリシーを実際にSDDC環境で使用してみます。Check Point vSECを使用して、VMware vCenterのデータセンター・オブジェクトやNSXのセキュリティ・グループを動的に更新する方法、そしてチェック・ポイントのセキュリティ・ポリシーで動的オブジェクトを利用する方法について学習します。

このモジュールで学習する内容は次のとおりです。

このモジュールを終えると、動的オブジェクトが更新される仕組みについて十分な知識を得て、SDDC動的オブジェクトはきめ細かな管理が可能であり、セキュリティ・ポリシー内で容易かつ自動的に更新できることを理解できます。動的オブジェクトを使用すると、変化するIPアドレスの管理や変更されたセキュリティ・ポリシーの配信を手動で行う必要がなくなります。

HOLラボに関する注: このHOLチェック・ポイント・パートナー・ラボ環境は、すでにセットアップが完了しており、次の設定が行われています。

周辺コンポーネント:


vCenterおよびNSX Managerのデータセンター・オブジェクトの操作


ここでは、Check Point SmartDashboardを使用してCheck Point Security Managementサーバに接続し、手順に沿ってvCenterから動的SDDCデータセンター・オブジェクトを、NSX Managerからセキュリティ・グループを取得します。


 

vCenterのデータセンター・オブジェクトの表示

 

メイン・コンソールでCheck Point SmartDashboardを起動します。パスワードとして「VMware1!」と入力し、Enterキーを押します。

  1. SmartDashboardに接続したら、[Firewall] タブをクリックします。
  2. 左下のパネルのオブジェクト・ツリーで [Servers and OPSEC] のアイコンをクリックします。
  3. [Servers] をクリックしてノードを展開します。
  4. [Data Center] をクリックしてノードを展開します。
  5. [vcsa-01a.corp.local] をダブルクリックします。

 

 

vCenter Serverのプロパティ - vSECコントローラからvCenterへの接続のテスト

 

vcsa-01a.corp.localオブジェクトをダブルクリックすると、[vCenter Server Properties] ウィンドウが表示されます。

このラボ用のデーセンター・サーバ・オブジェクトと接続は、すでに作成、確立されています。

このウィンドウは、vCenterのサービス・アカウント情報を定義するために使用します。この情報は、vSECがvCenterと通信し、SICを確立する際に必要となります。

  1. [Test Connection] ボタンをクリックして、vCenterへの接続をテストします。vSECコントローラからvCenter ServerへのSICが確立されている場合は、[Connection status] に緑色で「Connected」と表示されます。
  2. [OK] をクリックしてウィンドウを閉じます。

 

 

NSX Managerのデータセンター・オブジェクトの表示

 

先ほどと同様に、左下のパネルのオブジェクト・ツリーで [Servers and OPSEC] のアイコンをクリックします。

  1. [Firewall] タブが開かれていることを確認します。
  2. [Servers] をクリックしてノードを展開します。
  3. [Data Center] をクリックしてノードを展開します。
  4. [nsxmgr-01a.corp.local] をダブルクリックします。

 

 

NSX Serverのプロパティ - vSECコントローラからNSX Managerへの接続のテスト

 

nsxmgr-01a.corp.localオブジェクトをダブルクリックすると、[NSX Server Properties] ウィンドウが表示されます。

このラボ用のデーセンター・サーバ・オブジェクトと接続は、すでに作成、確立されています。このウィンドウは、NSX Managerのサービス・アカウント情報を定義するために使用します。この情報は、vSECがNSX Managerと通信し、SICを確立する際に必要となります。

  1. [Test Connection] ボタンをクリックして、NSX Managerへの接続をテストします。vSECコントローラからNSX ManagerへのSICが確立されている場合は、[Connection status] に緑色で「Connected」と表示されます。
  2. [OK] をクリックしてウィンドウを閉じます。

 

データセンター・オブジェクト・グループの操作


vCenter ServerおよびNSX Managerとの接続が正しく確立されていることを確認できました。これで、動的データセンター・オブジェクトを利用する準備が整ったことになります。このレッスンでは、vCenterおよびNSX Managerを照会し、チェック・ポイントのセキュリティ・ポリシーで動的データセンター・オブジェクトを利用する方法について学習します。動的セキュリティ・ポリシーでは、静的なIPアドレスやホスト名、ネット範囲の代わりに、動的データセンター・オブジェクトを使用します。

すでに述べたように、データセンター・オブジェクトはvCenterから、セキュリティ・グループはNSX Managerから取得できます。これらのオブジェクトは動的です。つまり、SDDC環境でvCenterからVMを作成し、NSXのセキュリティ・グループに参加させる際、オブジェクトに関する情報がvSECコントローラとの間で動的に交換され、チェック・ポイントのセキュリティ・ポリシー内で自動的に更新されます。動的オブジェクトには、次の2つの大きなメリットがあります。

運用効率の向上 - データセンター・オブジェクトは、セキュリティ・ポリシーの中で即座に利用可能となります。データセンター・オブジェクトは完全にvCenterに適合しており、オブジェクトの属性はチェック・ポイントのIdentity Awareness、SmartLog、SmartViewTrackerで認識できます。

動的SDDCセキュリティ・ポリシー - セキュリティ・グループ・オブジェクトは、チェック・ポイントのセキュリティ・ポリシーを自動的に更新、継承します。ファイアウォールのルールベースをプッシュ配信する必要はありません。


 

データセンター・オブジェクト・グループの表示

 

再び、SmartDashboardの左下のパネルのオブジェクト・ツリーから作業を開始します。

  1. [Network Objects] のアイコンをクリックします。
  2. [Groups] を右クリックし、[Groups] にマウス・カーソルを合わせます。
  3. [Data Center Objects Group] をクリックします。

 

 

データセンター・オブジェクト・グループの管理

 

[Data Center Objects Group] ウィンドウが表示されます。

 

 

vCenterの動的データセンター・オブジェクトの選択

 

  1. [+] 記号をクリックし、表示されたサーバがvCenterであることを確認します。vcsa-01a.corp.localというデータセンター・オブジェクトが表示されるはずです。このウィンドウでは、vCenterとNSX Managerのデータセンター・オブジェクトを切り替えることができます。
  2. その下のセクションで、チェック・ポイントのセキュリティ・ポリシーに取り込むvCenterの動的オブジェクトを選択できます。app-01a.corp.local、db-01a.corp.local、web-01a.corp.localという3つのラボ用VMのチェック・ボックスを選択します。

注: ここには、SDDCデータセンターおよびクラスタに存在するvCenter Serverの階層が表示されます。このラボでは、データセンターRegionA01およびクラスタRegionA01-COMP01のvCenterを使用します。

 

 

NSX Managerの動的セキュリティ・グループ・オブジェクトの選択

 

  1. [+] 記号をクリックしてvCenterとNSX Managerを切り替え、NSX Managerを選択します。nsxmgr-01a.corp.localというデータセンター・オブジェクトが表示されるはずです。
  2. その下のセクションで、チェック・ポイントのセキュリティ・ポリシーに取り込むNSX Managerのセキュリティ・グループ・オブジェクトを選択できます。App Group、DB Group、Web Groupという3つのセキュリティ・グループのチェック・ボックスを選択します。
  3. [OK] をクリックします。

 

 

データセンター・オブジェクト・グループ名の入力

 

データセンター・オブジェクト・グループには名前が必須であることを示すメッセージが表示されます。

  1. [Name] フィールドに「TestObjectsGroup」と入力します。
  2. [OK] をクリックして、新しいデータセンター・オブジェクト・グループを保存します。このグループは、[Network Objects] の [Groups] 以下に表示されます。

 

 

新規作成したデータセンター・オブジェクト・グループの表示

 

再び、SmartDashboardの左下のパネルのオブジェクト・ツリーから作業を開始します。

  1. [Network Objects] のアイコンをクリックします。
  2. [Groups] をダブルクリックして展開します。
  3. 表示および編集の対象となる [TestObjectsGroup] をダブルクリックします。先ほど選択したオブジェクトが表示されます。
  4. [OK] をクリックしてウィンドウを閉じます。

このレッスンでは、新たにデータセンター・オブジェクト・グループを作成しました。次のレッスンでは、vCenterおよびNSX Managerの設定画面に移動して、作成したデータセンター・オブジェクトやセキュリティ・グループをそれぞれ確認します。これらの動的オブジェクトは、Check Point Security Managementサーバに取り込むことができます。

 

vCenterおよびNSX Managerでのデータセンター・オブジェクトの表示


vCenterの動的データセンター・オブジェクトと、NSX Managerのセキュリティ・グループに注目すると、Check Point vSECとVMware NSXの統合のコンセプトとメリットを理解しやすくなります。


 

vCenterでの動的データセンター・オブジェクトの確認

 

メイン・コンソールのデスクトップでChromeブラウザのアイコンをダブルクリックし、vSphere Web Clientを起動します(起動していない場合)。vSphere Web Clientのホーム画面が表示されます。

  1. [Home] タブの [VMs and Templates] アイコンをクリックします。

 

 

vCenterの動的データセンター・オブジェクトの表示 - VM

 

現在、左側のパネルには、vCenterのvcsa-01a.corp.localとトップ・レベル・データセンター・オブジェクトRegionA01のオブジェクト・ツリーが表示されています。このデータセンターには、動的オブジェクトとして、app-01a.corp.local、db-01a.corp.local、web-01a.corp.localというVMが含まれています。

SDDCは、必要に応じてVMを起動または停止し、vMotionで移動できる動的な環境です。VMのIPアドレスも動的に変更されます。vSECとvCenterおよびNSX Managerが統合された環境では、SDDC環境内での変化に合わせて、チェック・ポイントのセキュリティ・オブジェクトとセキュリティ・ポリシーが随時更新されます。

 

 

VMの概要の表示

 

  1. 左側のパネルで [web-01a.corp.local] をクリックします。
  2. [Summary] タブをクリックします。このVMの属性が表示されます。このVMは実行中で、172.16.10.11というIPアドレスが割り当てられており、Web GroupおよびVMsという2つのセキュリティ・グループのメンバーであることが分かります。
  3. app-01a.corp.localとdb-01a.corp.localについても、同じ操作を行います。
  4. vSphere Web Clientの最上部にある [Home] ボタンをクリックします。このボタンは、vSphere Web Clientというウィンドウ・タイトルと検索フィールドの間に配置されています。

[Home] ボタンをクリックすると、いつでもvSphere Web Clientのトップ・レベル・ビューに戻ることができます。

 

 

NSX Managerのセキュリティ・グループの表示

 

[Home] ドロップダウン・リストから次の操作を行います。

  1. [Networking & Security] を選択します。
  2. 左側のパネルを下方向にスクロールし、[Service Composer] をクリックします。NSX Manager 192.168.110.15の [Security Groups] タブが表示されます。タブは切り替え可能で、列のサイズや順序も変更できます。

[Service Composer] では、NSX内のセキュリティ・グループを定義できます。このラボ用のセキュリティ・グループはすでに作成済みです。この画面に表示されるセキュリティ・グループは、先ほどチェック・ポイントのセキュリティ・ポリシーに取り込んだ動的データセンター・オブジェクトです。

 

 

VMsセキュリティ・グループのメンバーシップの表示

 

このリストには、各セキュリティ・グループに関連付けられているVMの数が表示されています。

  1. [Web Server] の行をクリックして選択状態にします。[Virtual Machines] 列に「1」という数字が表示されています。これは、1つのVMがWeb Groupセキュリティ・グループのメンバーになっていることを示しています。
  2. メンバーになっているVMを確認するには、この数字をクリックします。すると、web-01a.corp.localがWeb Groupセキュリティ・グループのメンバーであることが確認できます。

チェック・ポイントのセキュリティ・ポリシーでは、vCenterの動的データセンター・オブジェクトとNSX Managerのセキュリティ・グループを使用しますが、通常、動的データセンター・オブジェクトとセキュリティ・グループは、組織固有の要件に基づいて作成することになります。

セキュリティ・グループは、機能またはセキュリティ・ゾーン単位でグループ化したVMに合わせて作成するのが一般的です。ただし、何が最適であるかは組織によって異なります。

このラボでは、Web、アプリケーション、データベースという一般的な3階層モデルを表現するために、それぞれの階層に対応したNSXセキュリティ・グループを用意しています。また、各VMを対応するセキュリティ・グループに自動登録するため、VMの名前には一定のルールを設けています。

例えば、Webサーバとして機能するすべてのVMの名前には、「web」という文字列を含めています。そして、これらのVM用に専用の動的セキュリティ・グループを用意しています。名前に「web」が含まれるすべてのVMは、Webサーバ用のセキュリティ・グループに自動で追加され、そのグループの属性を継承します。これにより、動的セキュリティ・ポリシーの作成や、Web層、アプリケーション層、データベース層の間のマイクロセグメンテーションに基づく検査およびポリシー実施を容易に行うことが可能となっています。右上の [x] をクリックして [Web Group - Virtual Machines] ウィンドウを閉じます。

 

 

Service Composer -- セキュリティ・グループの属性

 

[Service Composer] 画面での作業を続けます。

  1. Web Groupというセキュリティ・グループをクリックし、このグループを選択状態にします。
  2. 鉛筆アイコンにマウス・カーソルを合わせます。セキュリティ・グループを編集するためのボタンであることを示すヒントが表示されます。ここからは、セキュリティ・グループがもたらす強力な機能と柔軟性を見ていきます。

鉛筆アイコンをクリックすると、[Edit Security Group] ウィンドウの1つ目の項目である [Name and description] ページが表示されます。

 

 

動的なメンバーシップ -- セキュリティ・グループの編集 -- Web Group

 

[Service Composer] 画面での作業を続けます。

  1. 鉛筆アイコンをクリックすると、[Edit Security Group] ウィンドウの1つ目の項目である [Name and description] ページが表示されます。
  2. 左側のパネルで2つ目の項目 [Define dynamic membership] をクリックします。名前が「web」で始まるという条件を満たすすべてのVMが動的にWeb Groupセキュリティ・グループに追加される設定になっていることが分かります。
  3. 残りの項目もすべて参照して、セキュリティ・グループでは非常に柔軟な定義が可能であることを確認してください。
  4. 5つ目の項目 [Ready to complete] で [Cancel] ボタンをクリックし、[Service Composer] 画面に戻ります。

このラボ用のセキュリティ・グループはすでに作成済みですが、セキュリティ・グループの作成方法や、作成および編集を行う場所を理解しておいてください。

 

 

Infected VM Groupセキュリティ・グループの表示

 

  1. Infected VM Groupというセキュリティ・グループをクリックし、このグループを選択状態にします。
  2. 鉛筆アイコンをクリックしてこのグループを編集します。

[Edit Security Group] ウィンドウの1つ目の項目である [Name and description] ページが表示されます。

 

 

グループに含めるオブジェクトの選択 -- セキュリティ・グループの編集 -- Infected VM Group

 

[Service Composer] 画面での作業を続けます。

  1. 左側のパネルで2つ目の項目 [Define dynamic membership] をクリックします。このページでは何も設定されていません。
  2. 左側のパネルで3つ目の項目 [Select objects to include] をクリックします。
  3. Infected VM Groupの定義は、動的なメンバーシップに基づいているのではなく、VMにANTI_VIRUS.VirusFound.threat=highまたはDATA_SECURITY.violationsFoundのセキュリティ・タグが設定されているかどうかであることが分かります。

このタグをVMに設定する方法は2つあります。一般的な方法は、チェック・ポイントの高度なセキュリティ機能のトリガーや、アンチウイルス、アンチボット、またはIPS機能のトリガーを使用して、セキュリティ侵害を受けたVMに自動でタグ付けすることです。もう1つの方法は、VMwareの管理者が手動でタグ付けすることです。

セキュリティ侵害を受けた(マルウェアに感染した)VMに対し、データセンター・セキュリティ違反のセキュリティ・タグを動的に設定し、そのVMを即座にInfected VM Groupセキュリティ・グループに登録するという仕組みにより、問題のあるVMを速やかに検出、隔離することが可能となります。Infected VM Groupセキュリティ・グループのオブジェクトは、すでにチェック・ポイントのセキュリティ・ポリシーに定義されており、同セキュリティ・グループに登録されたメンバーは、他のVMとのトラフィックをすべて破棄されるという形で隔離されます。セキュリティ侵害を受けたVMが検出された場合、そのVMには動的にセキュリティ・タグが設定され、vSECとNSXの統合を通じて、Infected VM Groupグループに自動登録されるため、問題のVM経由でSDDC全体に被害が拡大することを防止できます。

詳細については、モジュール3で学習します。

 

セキュリティ・ポリシーに定義されたルールの表示


前回のレッスンでは、VMware vCenterおよびNSXの動的データセンター・オブジェクトとセキュリティ・グループについて詳しく学習しました。また、vSECコントローラとNSXの統合を通じて、動的オブジェクトをチェック・ポイントのセキュリティ・ポリシーに簡単に取り込めることを学びました。動的オブジェクトは、Check Point Security Managementで管理し、継続的にポーリングして更新できます。このレッスンでは、動的データセンター・オブジェクトを実際のセキュリティ・ポリシーで利用する方法について学習します。


 

SmartDashboardの起動

 

メイン・コンソールのデスクトップでSmartDashboard R77.30のアイコンをダブルクリックして、Check Point SmartDashboardを起動します。SmartDashboardは、組織全体のセキュリティ・ポリシーや物理/仮想セキュリティ・ゲートウェイを管理するためのGUIです。

SmartDashboardの認証情報を入力するウィンドウが表示されます。ユーザ名とIPアドレスは自動入力されています。パスワードとして「VMware1!」と入力し、[Login] ボタンをクリックします。

 

 

SmartDashboardでのセキュリティ・ポリシーの表示

 

[Login] ボタンをクリックすると、SmartDashboardが表示されます。画面上部には、[Firewall]、[Application Control and URL Filtering]、[Data Loss Protection]、[IPS]、[Threat Prevention] などのタブが並んでいます。

  1. [Firewall] タブをクリックします。
  2. 左上のパネルで [Policy] をクリックします。
  3. 各セクション・ヘッダの [+] 記号をクリックしてルールを展開すると、そのセクションに含まれるすべてのルールが表示されます。

[Policy] 画面には、次のようなセクション・ヘッダを持つセキュリティ・ルールベースが表示されます。

 

 

SDDCマイクロセグメンテーション

 

ここでは、マイクロセグメンテーションについて見ていきます。

VMware NSXは、ネットワークの分離とセグメント化の機能を内蔵しており、SDDCのマイクロセグメンテーションを容易に実現できます。VLANやACL、ファイアウォール・ルール、物理ファイアウォール、ルータの設定は必要ありません。

Check Point vSECは、コンテキスト・ベースのマイクロセグメンテーションやSDDCの東西トラフィックの可視化、統合セキュリティ管理などの機能でVMware NSXを強力に補完します。

セキュリティ・ポリシーに含まれるData Center Micro Segmentationルールを表示します。このルールでは、どのような内容が定義されているでしょうか。

このルールでは、Web Groupセキュリティ・グループ宛てのトラフィックに適用するマイクロセグメンテーション、検査、セキュリティ・ポリシーについて定義しています。ルール9では、任意の送信元からWeb Groupセキュリティ・グループのメンバーに対する、httpまたはhttps経由での通信を許可しています。ルール10では、任意の送信元からWeb Groupセキュリティ・グループのメンバーに対するその他のトラフィックをすべて破棄しています。

  1. [Web_Group] にマウス・カーソルを合わせます。すると、データセンター・オブジェクト・グループであるWeb Groupセキュリティ・グループ・オブジェクトのメンバーが表示されます。web-01a.corp.localがWeb Groupのメンバーであることが分かります。

 

 

SDDCにおける動的なポリシー実施

 

ここでは、動的なポリシー実施(Dynamic Enforcement)について見ていきます。

アプリケーションと物理インフラストラクチャ間の任意の場所に配置可能なVMware NSXネットワーク・ハイパーバイザは、各仮想インタフェースで分散してポリシーを実施できます。VMware NSXとCheck Point vSECを統合すると、高度なセキュリティ機能を動的に配置できるようになります。

セキュリティ・ポリシーに含まれるDynamic Enforcementルールを表示します。このルールでは、どのような内容が定義されているでしょうか。

このルールでは、Web Groupセキュリティ・グループと★DB Group★セキュリティ・グループ間のトラフィックに対し、動的にポリシーを適用しています。ルール11では、Web Groupセキュリティ・グループとDB Groupセキュリティ・グループの間で行われる、MS SQLサービスおよびICMPサービス経由の通信のみを許可しています。ルール12では、Web Groupセキュリティ・グループのメンバーではない送信元による、★DB Groupセキュリティ・グループ★のメンバーに対するMS SQLサービス経由の通信を破棄しています。

  1. [DB_Group] にマウス・カーソルを合わせます。すると、データセンター・オブジェクト・グループであるDB Groupセキュリティ・グループ・オブジェクトのメンバーが表示されます。db-01a.corp.localというVMがDB Groupのメンバーであることが分かります。

 

 

SDDCにおける高度な脅威対策

 

ここでは、高度な脅威対策について見ていきます。

チェック・ポイントの高度な脅威対策は、ボットネットや標的型攻撃、APT(Advanced Persistent Threat)攻撃、ゼロデイ攻撃などの高度なサイバー攻撃をプロアクティブに防御する多層防御のセキュリティを提供します。VMware NSXでは、各ワークロード間にチェック・ポイントの高度なセキュリティ機能を配置し、アプリケーション間の通信を制御できるため、ネットワーク構成を簡素化し、データセンターに設定するVLAN数を削減できます。

セキュリティ・ポリシーに含まれるAdvanced Threat Prevention Scenariosルールを表示します。このルールでは、どのような内容が定義されているでしょうか。

このルールでは、VMに高度な脅威対策を適用しているほか、SDDC内でのマルウェアやボットの移動を阻止するため、侵害を受けたVMを隔離しています。

チェック・ポイントの脅威対策エンジンによって、マルウェアに感染したVMが検出された場合、そのVMには「感染」というセキュリティ・タグが設定されます。定義済みのSDDC脅威/リスク・ルールに基づき、セキュリティ・タグが設定されたことがNSXに通知されます。そしてそのセキュリティ・タグに基づき、問題のVMがInfected VM Groupセキュリティ・グループに登録されます。これ以降、問題のVMとの間で発生するすべてのトラフィックは、直ちに破棄されます。

  1. 感染VMオブジェクトにマウス・カーソルを合わせます。感染VMは表示されるでしょうか。これについては、モジュール3で学習します。

モジュール3では、実際にトラフィックを発生させ、セキュリティ・ポリシー・ルールの実施状況をCheck Point SmartLogで確認します。

 

まとめ


このモジュールでは、動的オブジェクトが更新される仕組みについて十分な知識を得ると共に、SDDC動的オブジェクトはきめ細かな管理が可能であり、セキュリティ・ポリシー内で容易かつ自動的に更新できることを学習しました。動的オブジェクトを使用すると、変化するIPアドレスの管理や変更されたセキュリティ・ポリシーの配信を手動で行う必要がなくなります。

ここまで大変お疲れ様でした。

次のモジュールにお進みください。


 

モジュール2の終了

 

以上で、モジュール2のレッスンはすべて終了しました。

Check Point vSECとNSXによるSDDCの保護について、さらに詳しく知りたい場合は、次のいずれかの方法で追加資料をご覧ください。

ご興味のある次のいずれかのモジュールにお進みください。

 

モジュール3 - SDDC内部の東西トラフィックの保護(30分)

はじめに


重要:ラボを初めて開始する際は、まずメイン・コンソールの [Lab Status] の表示を確認してください。[Lab Status] [READY] になっていたら、ラボを開始してください。[FAILED] の場合はいったんラボを終了し、新しいラボを開始してください。

このモジュールでは、SDDC内の東西トラフィックを内部のセキュリティ脅威から保護する方法について学習します。動的データセンター・オブジェクトを利用した動的セキュリティ・ポリシーをvSECがSDDCで実施する仕組み、東西トラフィックに高度な脅威対策とIPSを適用する方法について学びます。

さらに、チェック・ポイントの脅威対策とIPS Software Bladeを有効にし、東西トラフィックにリアルタイムのセキュリティ対策を適用した後、シャドウITとして脆弱性のあるWebサーバを立ち上げ、IPSでこのWebサーバのセキュリティ違反を検出するデモを実施します。

脅威対策とvSECの組み合わせは、既知の脅威、そして未知の脅威の多くを防御する多層防御のセキュリティを提供します。Check Point vSECには、次の脅威対策機能が含まれています。

HOLラボに関する注: このHOLチェック・ポイント・パートナー・ラボ環境は、すでにセットアップが完了しており、次の設定が行われています。

  1. 1. VMware vCenter ServerおよびNSX Managerの導入
  2. 2. vSphereデータセンター、クラスタ、およびデータセンター・オブジェクトの設定
  3. 3. クラスタを構成するESXiホストでのエージェントVMの設定
  4. 4. vCenterのランタイム設定
  5. 5. NSX Managerの適切なクラスタへのインストール
  6. 6. vSECゲートウェイで使用するIPアドレス・プールの準備
  7. 7. Check Point Security Managementサーバの導入
  8. (p.75)
  9. 8. vSECゲートウェイ・サービスの設定とvSECコントローラのvCenterおよびNSX Managerへの登録
  10. 9. vSECクラスタ・オブジェクトの定義
  11. 10. vSECゲートウェイ・インスタンスのクラスタ・メンバーとしての割り当て

ベスト・プラクティス: 各VMへのVMwareツールのインストール

ベスト・プラクティス: ポート・グループへのSpoof Guardの適用

周辺コンポーネント:


SDDC Dynamic Enforcement


In this lesson you will learn how Check Point vSEC supports dynamic security policy enforcement for the SDDC.  When dynamic data center object changes, these changes are updated in real time and automatically.  There is no need to make manual changes or push security policy to the vSEC Gateways.  


 

Dynamic SDDC Changes -- IP Address

It is important for you to see how dynamic objects helps with operational efficiency in the SDDC.  The SDDC is dynamic environment where VMs spin up, go to sleep, change IP address, etc.    

To demonstrate how vSEC integration with NSX provides dynamic security policy, you will change the IP address on the web server (web-01a.corp.local) and verify:

  1. The web-01.corp.local VM still inherits the security policy of the Web Security Group without a security policy push
  2. The change IP address is updated automatically within Identity Awareness, which you will see in SmartLog.

In the next steps, you will open a console connection to web-01a.corp.local and change the IP address of the web server.

 

 

Use vSphere Web Client to Open Console Connection

 

Open vSphere Web Client, then from left panel, click on web-01a.corp.local, then click on the Summary tab.  

Note:

  1. The security group membership of web-01a.corp.local is Web Group and VMs.
  2. The IP address for web-01a.corp.local is 172.16.10.11.
  3. Now you will click on the "black box" to launch a console connection to the web server.

 

 

Open Console Connection to Web Server

 

You have launched a console connection to web-01a.corp.local and are presented with console access to the web server.  

Log in with the following credentials:

  1. login: root  
  2. Password: VMware1!  

 

 

Linux Commands

 

From the command line type and press Enter:

ping 172.16.30.11

You will initiate ping request to db-01a.corp.local (DB Server) on IP address 172.16.30.11

 

 

Result of ping 172.16.30.11 test to db-01a.corp.local

 

From the command line, type CTRL+C to stop ping test.

  1. Result: you see that the db server did respond to the web server's ping request. Web server is able to communicate with the db server via ICMP requests.
  2. CTRL+C to quit

Leave the console connection open.   You will continue working from this in the next steps.

 

 

Verify Dynamic Enforcement Rules in Security Policy

 

The web server is able to communicate with the db server via ICMP requests.

What Check Point security policy rules allows for communication from the web server to the db server via ICMP requests (ping)?  

From the Main Console desktop, open SmartDashboard.  

  1. Click on the Firewall tab.  
  2. Click hive to expand the Dynamic Enforcement section title.  

You see Dynamic Enforcement RULE 11 allows ICMP communication from the Web Group to the DB Group.  The web server is a member of the Web Group Security Group, therefore the web server should be able to communicate with the db server.  

Leave SmartDashboard open.  

Next you will open SmartLog to see the enforcement of this security policy rule in the logs.  

 

 

Open SmartLog

 

From within SmartConsole

  1. Click the SmartConsole tab
  2. Click SmartLog from the drop down

SmartLog dashboard is presented to you.

 

 

Explore SmartLog Log Entries for Dynamic Enforcement

 

Once you have opened SmartLog, you will look for logs respective to RULE 11.

Use the SmartLog search window to find this log fast!  HINT: How to get here?  See substeps for expanded screen captures for leveraging SmartLog search filters.

  1. Click once in the search field
  2. Select Rule, select rule: 11
  3. Select Time from search, and select Past Hour.
  4. Then click Refresh

For step by step instructions on how to use super cool SmartLog search filters, follow the substeps provided here just for you.  

 

 

Cool SmartLog Search Filters

 

When you click on the search field in SmartLog, you are presented with search filters

  1. Click on the search field
  2. Click Rule:

 

 

SmartLog Search Filter by Rule

 

Once you select rule, you are presented with a list of rules

  1. Click on Policy:Standard Number:11 Name:Dynamic Enforcement

 

 

SmartLog Search Filter by Time

 

Now that you have the rule filter turned on, you will turn on another filter to search by time.

  1. Click Time:

 

 

SmartLog Search Filter by Time -- Last Hour

 

Now that you selected Time: filter, you are presented with a list of selections.  You will search for the past hour to see the ping traffic you just generated.  

Important Note: if you paused your lab and more than an hour of time has elapsed since you generated ping traffic in the previous steps, adjust your search time filter to Past 24 Hours!

  1. Click Past Hour
  2. Click the Refresh arrow

Note: the search field now reflects the filters you selected: by rule and by time.  

You are now presented with the logs that specifically match the customized search you just performed in SmartLog.

 

 

Expand SmartLog Log Details

 

Now you are now presented with the logs that specifically match the customized search you just performed in SmartLog.

Double click the log at the top of the list. This will provide you with the log details.

You have confirmed the web server was able to communicate with the db server by way of connection test, and you confirmed enforcement of the security policy for dynamic enforcement in SmartLog.  

Again, the reason for this communication is web server is in the Web Group (Security Group) and the db server is in the DB Group (Security Group) and communication from the Web Group to the DB Group via ICMP is allowed in the security policy.

Next you will change the IP address of the web server and confirm that communication still works and the security policy is automatically enforced with the dynamic change of the data center object within vSphere.  

  1. Close the Log Details window.  
  2. Clear the search window by typing X.

Leave SmartLog open.

 

 

Change IP addresses of web-01a.corp.local

 

Working again from the vSphere Web Client and the console connection...

From the command line type the following command and press Enter:

ifconfig eth0 172.16.10.12 netmask 255.255.255.0

This command changes the web-01a.corp.local ethernet 0 interface IP address to 172.16.10.12.

 

 

Verify IP Address Changed on web-01a.corp.local

 

From the command line type the following command and press Enter:

ifconfig 

Result of this command confirms the IP address has changed to 172.16.10.12

 

 

Run ping test from web-01a.corp.local to db-01a.corp.local

 

Wait about 30 seconds, the rerun the connection test.

From the command line, type the following command and press Enter:

ping 172.16.30.11

Result: you see that the web server is still able to communicate with the db server via ICMP requests (ping request).  

You understand that IP address changes are automatically updated with the vSEC integration with NSX.  The web server is a member of the Web Group Security Group in NSX and the dynamic object in Check Point Security Management utilized in the security policy for the Web Group is updated automatically, in real time, without the need for policy push or any manual intervention.

How does this work?  Let's go take a look at SmartLog and explore how the Virtual Machine information is updated.

 

 

View Identity Awareness Updates in SmartLog

 

Identify Awareness is the feature within Check Point that provides updates to the SmartLog regarding SDDC dynamic objects: VM and IP address to its respective Security Group membership.

Working again from SmartLog,

  1. Click in the search field and select time: Past Hour.
  2. Scroll through the log entries for the last hour until you find the last entry of web-01a.corp.local.  You will see an entry from Identity Awareness indicating log out of the web-01a.corp.local from the Web Group (Security Group Object).
  3. Next you will scroll up and see a log entry showing web-01a.corp.local logging into Identity Awareness with its new IP address.

 

 

Expand SmartLog Log Details

 

You have confirmed the web server logged out of the Web Server Group with IP address 172.16.10.11.

Now you have confirmed that web server logged into Identify Awareness (IA) with 172.16.10.12.

  1. Double click the log for more details.
  2. Close the Log Details window.  
  3. Clear the search window by typing X.

Again, the reason for this communication is web server is in the Web Group (Security Group) and the db server is in the DB Group (Security Group) and communication from the Web Group to the DB Group via ICMP is allowed in the security policy.

The change of IP address of the web server is updated and the security policy is automatically enforced with the dynamic change of the data center object.  

Leave SmartLog open.

In the next lesson, you will learn a bit about micro-segmentation.

 

 

Change web-01a.corp.local IP address back

 

Now you will change the IP address of web-01a.corp.local back to its original IP address and then ping test once again.  

Working again from vSphere Web Client and console connection to web-01a.corp.local:

From the command line, type the following commands followed by pressing Enter:

ifconfig eth0 172.16.10.11 netmask 255.255.255.0
  1. Wait 30 seconds
ping 172.16.30.11
  1. CTRL+C

You can close this console window.  

In this lesson, you learned how dynamic enforcement works and how dynamic enforcement can greatly streamline security operations.  

In the next lesson, you will learn a bit about micro-segmentation.

Good job!

 

SDDC Micro-Segmentation


In this lesson, you will learn about Check Point vSEC integration with VMware NSX allows dynamic insertion of advanced security protection between workloads enabling distributed enforcement at every virtual interface.

The integration automates and simplifies the provisioning of vSEC Gateways into the NSX virtual fabric to protect East-West traffic from lateral movement of threats enabling feasible micro-segmentation.

Check Point vSEC provides network micro-segmentation, allowing for firewall controls and security for East-West traffic inside the data center.  Micro-Segmentation minimizes the risk and impact of data breaches.  A micro-granular security model with the ability to tie security to individual workloads and the agility to provision policies automatically.

vSEC micro-segmentation provides fine-grained network controls enable unit-level trust, and flexible security policies can be applied all the way down to a network interface (in a physical network, this would require deploying a physical firewall per workload).


 

How VMware NSX Works

 

VMware NSX (network virtualization and security extension) platform for the Software-Defined Data Center (SDDC) makes micro-segmentation possible.  NSX embeds networking and security functionality that is typically handled in hardware directly into the hypervisor.

NSX delivers the operational model of a virtual machine for networking and security and makes network micro-segmentation operationally feasible, providing the foundation for the SDDC that enables automated deployment, orchestration and scale-out of advanced security services.

NSX is an integrative solution that can seamlessly be deployed on any IP network, including existing data center network designs or next generation fabric architectures from any networking vendor and reproduces network functions in software: virtual switches, virtual routers, virtual firewalls, virtual load balancers, QoS and QoE.

An NSX deployment consists of:

 

 

NSX Distributed Firewall (DFW) Makes Micro-Segmentation Possible

 

VMware NSX Distributed FireWall (DFW) is the distributed Layer 2-4 firewall component for East-West traffic inspection provided within the NSX solution.  DFW provides stateful firewall capability down to each vNIC of a Virtual Machine and operates at the hypervisor kernel layer delivering near line rate performance.

A DFW instance is created per Virtual Machine's vNIC.  This instance is located between the VM and the Virtual Switch (IE: VDS port-group VLAN-backed, or Logical Switch).  DvFilter slot 2 is allocated for the DFW instance.  All ingress and egress packets to and from this VM must pass through the DFW.

By default, traffic is secured by DFW.  With the Check Point vSEC integration, explicit traffic redirection to Check Point vSEC Gateway is defined through VMware NSX Service Composer.

Global management of DFW is performed though the vSphere Web Client under the NSX "Home" tab.

Security Policy rules can be written using vCenter objects like VM, cluster, DVS port group, logical switch and so on.

NSX DFW fully supports vMotion and current active connections remain intact during the workload mobility event.

NSX DFW is a key component of micro-segmentation.

 

 

vSEC Micro-Segmentation to Protect Web Security Group

 

Now you will view micro-segmentation in the Check Point security policy RULE BASE.  

  1. Open SmartDashboard and click on the Firewall tab.
  2. Expand Data Center Micro Segmentation RULES 9 and 10. Can you tell what these rule are doing?

 

 

Generate Traffic to web-01a.corp.local

 

Now you will generate some test traffic and then view in SmartLog.  

From Main Console desktop, click the Chrome icon and launch vSphere Web Client.  

  1. From vSphere Web Client, navigate to VMs and Templates.
  2. From the left panel, click on the db-01a-corp.local.  Click on the Summary tab.  You will be presented with the VM Summary.  
  3. Click on "black box" to open console connection.

You will use the db-01a.corp.local to try to connect to web-01a.corp.local.

 

 

Run Ping Test from db-01a.corp.local to web-01a.corp.local

 

You will attempt ICMP ping from db-01a.corp.local to web-01a.corp.local.

Log into the DB Server with these credentials:

  1. User name: root
  2. Password: VMware1!
  3. ping 172.16.10.11
  4. [root@db-01a ~]#  CTRL+C

What is the result?  Can you explain?

 

 

Investigate SmartLog for ICMP Traffic from db-01a.corp.local to web-01a.corp.local

 

Launch SmartLog.

  1. Click on the SmartLog search field.  
  2. From drop down, select dst:web-01a.corp.local and time:Past Hour
  3. Click the Refresh arrow.

You are presented with your filtered set -- traffic in the last hour where the destination was web-01a.corp.local.

You see a log entry where db-01a.corp.local is the source and the service is ICMP echo request.

Click on the log depicting a stop sign.  This indicates the traffic was dropped.  Double click the log to be presented with SmartLog log details.  

 

 

SmartLog Log Detail for Dropped ICMP Attempt

 

After double clicking this specific log event, you are presented with log details.  

The traffic was dropped on RULE 10 Micro Segmentation.

You see the log details show the source is db-01a.corp.local and the destination is web-01a.corp.local.  The service type is ICMP echo request (ICMP/8).  

You see that web-01a.corp.local is a member of the Web Group Object (NSX security group named Web Group) and db-01a.corp.local is a member of DB Group Object (NSX security group named DB Group).

Close the Log Details box.

 

 

SSH Test from db-01a.corp.local to web-01a.corp.local

 

Working from the db-01a.corp.local console command line attempt an ssh connection to web-01a.corp.local:

ssh 172.16.10.11

What happens? Hint: wait a few seconds. Connection will time out.

 

 

Investigate SmartLog for ssh traffic from db-01a.corp.local to web-01a.corp.local

 

Once again, working from SmartLog:

  1. Click on the SmartLog search field.  
  2. From drop down, select dst:web-01a.corp.local and time:Past Hour
  3. Click the Refresh arrow.

You are presented with traffic in the last hour where the destination was web-01a.corp.local.

You see a log entry where db-01a.corp.local is the source and the service is ssh.

Click on one of the depicting a stop sign.  This indicates the traffic was dropped.  Double click the log to be presented with SmartLog log details.  

 

 

Expand SmartLog Log Details

 

Click to highlight this log event.  Then double click to open the Log Details.

After double clicking this specific log event, you are presented with log details.  

You see the log details show the source is db-01a.corp.local and the destination is web-01a.corp.local.  The service type is ssh (TCP/22).

You see also that web-01a.corp.local is a member of the Web Group Object (NSX security group Web Group) and db-01a.corp.local is a member of the DB Group Object (NSX security group named DB Group).  

The traffic was dropped on RULE 10 Micro Segmentation.  

Close the Log Details box.

In this lesson, you learned about micro-segmentation and how vSEC integration with NSX provides a perfect complementary solution.

In the next lesson, you will learn about turning on advanced threat prevention with Check Point IPS for the vSEC Gateway service.

 

SDDCにおける高度な脅威対策とIPSの組み合わせ


では、次のレッスンに進みましょう。ここまでのレッスンで、SDDCにおけるセキュリティの知識をかなり習得できているはずです。

このレッスンでは、チェック・ポイントの高度な脅威対策とIPSの組み合わせについて学習し、SDDC内の東西トラフィックの保護にIPSが効果的である理由を学びます。


 

SmartDashboardの起動

 

メイン・コンソールのデスクトップからSmartDashboardを起動します。

[Firewall] タブが選択された状態でSmartDashboardが表示されるはずです。別のタブが選択されている場合は、メニュー・リストの下にある [Firewall] タブをクリックします。

  1. 左側のパネルで [Network Objects] アイコンをクリックします。
  2. [Check Point] を展開します。vsecsvm-RegionA01-RegionA01-COMP01というvSECのクラスタ・オブジェクトが表示されます。このオブジェクトを展開すると、2つのvSEC SVMインスタンスが表示されます。
  3. [vsecsvm-RegionA01-RegionA01-COMP01] をダブルクリックします。

 

 

Check Point vSECのクラスタ・オブジェクトの表示

 

[Gateway Cluster Properties - General Properties] ウィンドウが表示されます。

このウィンドウには、先ほどのvSECクラスタの設定が表示されます。このクラスタは、vSECゲートウェイ・サービスを提供するVMの2つのインスタンスで構成されています。ウィンドウの設定プロパティは、このvSECクラスタに割り当てられているすべてのインスタンスに適用されます。

ウィンドウの中央部にある [Network Security] タブでは、vSECクラスタに対し次のSoftware Bladeを有効にしています。

左側のパネルから、各Software Bladeの設定を確認できます。

このレッスンでは、IPSの設定を見ていきます。

 

 

IPS固有の保護プロパティの表示

 

[Gateway Cluster Properties - General Properties] ウィンドウの左側のパネルで [IPS] をクリックします。

  1. IPS固有のプロパティ画面が表示されます。
  2. このvSECクラスタ(vSEC SVM)では、IPSが [Recommended Protection](推奨の保護機能)というプロファイルで有効にされており、保護の範囲を設定する [Protection Scope] では [Protect internal hosts only](内部ホストのみを保護)ラジオ・ボタンが選択されていることが分かります。
  3. [Protection Scope] のラジオ・ボタンを [Perform IPS inspection on all traffic](すべてのトラフィックでIPSによる検査を実施)に切り替えます。
  4. パフォーマンスに関する警告メッセージで [OK] をクリックします。

再度 [OK] をクリックして、[Gateway Cluster Properties - General Properties] ウィンドウを閉じます。

 

 

変更を加えたIPSポリシーのプッシュ配信

 

  1. [Save] をクリックします。
  2. [Install Policy] をクリックします。

セキュリティ・ポリシーの設定を [Perform IPS inspection on all traffic] に変更したため、vSECゲートウェイのセキュリティ・ポリシー設定を更新する必要があります。

 

 

1台のセキュリティ・ゲートウェイへのポリシーのインストール

 

  1. cpr7730 [Network Security] チェックボックスをオフにします。
  2. vsecsvm-RegionA01-RegionA01クラスタの [Network Security] と [Threat Prevention] の両チェック・ボックスが選択されていることを確認します。
  3. [OK] をクリックします。

 

 

[Installation Process] ウィンドウ

 

ポリシーが正しくインストールされたかどうかを確認します。このラボの場合、インストール完了までに数分かかります。

注: このラボでは、アンチスプーフィングがセキュリティ・ゲートウェイのインタフェースで無効に設定されているため、警告メッセージが表示されます。

このメッセージは無視してください。

[Close] をクリックします。

 

 

IPSのRecommend Protectionsプロファイルの表示

 

SmartDashboardの上部にはタブが並べられており、各機能の設定画面を素早く切り替えることができます。

次のタブが表示されています。

  1. [IPS] タブをクリックします。このタブをクリックすると、IPS固有のセキュリティ・ポリシー設定画面が表示されます。この画面では、環境固有のニーズに応じて、IPSのプロファイルや保護機能を簡単に変更できます。

ここでは、SDDCにおけるIPS保護機能の設定がいかに柔軟に行えるかを見ていきます。

 

 

IPSプロファイル、保護機能、IPSポリシーを実施しているセキュリティ・ゲートウェイ

 

[IPS] タブでは、概要の確認、IPS保護機能を実施するセキュリティ・ゲートウェイの指定、デフォルトおよび推奨IPSプロファイルの設定、Geo Protectionの有効化、ネットワーク例外の定義を行えます。

  1. ウィンドウの中央部には [IPS in My Organization] というセクションが表示されます。
  2. [Recommend Profile] という行の右側の列に「2 GWs are enforcing IPS policy」(2台のゲートウェイがIPSポリシーを実施)と表示されています。★Recommended Protectionプロファイル★を実施している実際のゲートウェイを確認する方法は複数あります。
  3. 左側のパネルで [Gateways] をクリックします。

 

 

IPSを実施しているゲートウェイ

 

左側のパネルで [Gateways] をクリックすると、[Gateways] ウィンドウが表示されます。

Recommended Protectionプロファイルを実施している2台のゲートウェイが表示されます。

 

 

IPSプロファイルの確認

 

  1. 左側のパネルで、今度は [Profile] をクリックします。
  2. [Recommended Protection] をダブルクリックします。

このプロファイルのプロパティ画面が表示されます。

 

 

IPSのRecommended Protectionプロファイルのプロパティ

 

[Profile Properties - Recommended Protection] ウィンドウが表示されます。

このプロファイルについて、特に次の点に注目してください。

  1. Recommended Protectionプロファイルは [Prevent](防御)に設定されている
  2. Recommended Protectionプロファイルは、IPSポリシーに従って有効化されている

続いて、IPSポリシーのプロパティを見ていきます。

 

 

IPSポリシーのプロパティ

 

[Profile Properties - Recommended Protections] ウィンドウの左側のパネルで [IPS Policy] をダブルクリックします。

このポリシー設定は、Recommended Protectionプロファイルで動作しているすべてのセキュリティ・ゲートウェイで有効となります。

vNICレベルでトラフィックを検査し、セキュリティ・ポリシーを実施するvSECゲートウェイ・サービスのVMは、次のように設定されています。

保護機能はきめ細かくカスタマイズできます。実際の環境では、Recommended Protectionプロファイルを複製し、特定のネットワークやゾーン、機能領域に必要な保護機能に合わせてプロファイルを編集、展開するのが一般的です。

  1. [Cancel] をクリックしてウィンドウを閉じます。

 

 

保護機能の詳細 -- タイプ別とプロトコル別

 

[IPS] タブの左側のパネルで、今度は [Protections] をクリックて展開します。

  1. [By Type] をクリックして展開します。
  2. [By Protocol] をクリックして展開します。
  3. [By Protocol] 以下にある各項目をクリックして展開します。次の保護機能が表示されます。

チェック・ポイントでは以前より、ネットワーク情報、アプリケーション制御、プロトコル異常、プロトコル・アノーマリ(プロトコル異常)、アプリケーション情報、Web情報をセキュリティ対策に活用しており、アプリケーションの振る舞い分析やヒューリスティック技術を熟知しています。

 

 

[Application Intelligence] の保護機能の展開

 

同じく [IPS] タブの左側のパネルにある [By Protocol] を見ていきます。

  1. [Application Intelligence] 以下にある各項目をクリックして展開します。各保護機能が表示されます。
  2. [Malware Traffic] を展開し、[Application Intelligence] の一部として利用可能な保護機能を確認します。

 

 

[Web Intelligence] の保護機能

 

引き続き、[IPS] タブの左側のパネルにある [By Protocol] を見ていきます。

  1. [Web Intelligence] 以下にある各項目をクリックして展開します。

各保護機能が表示されます。[Web Intelligence] の一部として利用可能な保護機能を確認します。

 

 

「シャドウIT」問題のシミュレート

ではここで、実際のIT環境で発生している問題を再現するちょっとしたゲームをしてみましょう。

一般ユーザがIT部門の許可を得ずにApache Webサーバ(IPアドレスは172.16.10.11)を立ち上げたという状況をシミュレートします。このような行為は、「シャドウIT」と呼ばれます。このApacheサーバは十分な設定が行われておらず、潜在的な脆弱性が存在します。

このような「動けばいい」程度の設定しか行われていないシャドウITは多くの組織に存在します。

シャドウITは、多くのセキュリティ担当者にとって厄介な問題となっています。SDDCトラフィックの80%を占める東西トラフィックが適切に検査されていなければ、組織全体が大きなリスクにさらされます。

脅威対策を導入し、セキュリティ状況を可視化していなければ、脆弱性のあるVMやマルウェア感染、ボット活動の有無を把握することはできません。

では、ゲームの開始です。脅威対策を導入したvSECゲートウェイで、問題のWebサーバに存在する脆弱性を検出できるかどうか、確かめてみましょう。

以降では、次の作業を行います。

では、実際に作業を始めていきましょう。

 

 

web-01a.corp.localへのコンソール接続

 

  1. vSphere Web Clientで [VMs and Templates] をクリックします。
  2. [web-01a.corp.local] をクリックします。
  3. 黒いボックスをクリックしてWebサーバへのコンソール接続を開始します。

 

 

web-01a.corp.localへのログイン

 

HOLの認証情報を入力します。

  1. ログイン・ユーザ名: root
  2. パスワード: VMware1!

 

 

/etc/httpd/conf.dディレクトリへの移動

 

コマンドラインから、Web設定ファイルのあるディレクトリに移動します。

cd /etc/httpd/conf.d
pwd

作業ディレクトリの場所を確認します。

ls

ファイルの一覧を表示します。

vhost.confファイルが一覧にあることを確認します。これが、viエディタで編集するファイルです。

 

 

Webサーバの設定変更

 

注: vhost.confファイルが、ラボ・マニュアルのスクリーン・キャプチャと全く同じ内容になるよう編集します。

想定どおりの結果が得られるよう、指示のとおりに作業してください。

コマンドラインでviエディタを使用し、vhost.confファイルを編集していきます。

  1. [root@web-01a conf.d]#というプロンプトで「vi vhost.conf」と入力します。
  2. 1行目で「<VirtualHost *:80>」にカーソルを合わせます。
  3. Insertキーを押し、「172.16.10.11」と入力して、次のようにします。<VirtualHost 172.16.10.11:80>
  4. Escapeキーを押します。
  5. 最終行に移動し、</VirtualHost>の前にカーソルを合わせます。
  6. Insertキーを押してからEnterキーを押して、</VirtualHost>の手前に改行を挿入します。
  7. Escapeキーを押します。
  8. 「:wq」と入力して変更内容を保存し、viを終了します。「"vhost.conf" written」というメッセージが表示されます。

vhost.confの編集が正しく行われていれば、Webサービスを開始できるはずです。編集が間違っている場合、Webサービスは開始できません。

 

 

vhost.confファイルの変更内容の確認

 

vhost.confファイルの内容を表示し、正しく編集されているかどうかを確認するため、次のコマンドを入力します。

cat vhost.conf

編集が正しいかどうかを確認します。正しく編集されていれば、スクリーン・キャプチャのようになっているはずです。

 

 

Apache Webサービスの開始

 

Apache Webサーバを開始するには、コマンドラインで次のように入力します。

service httpd start 

Webサービスが開始されると、「Starting httpd: [ OK ]」というメッセージが表示されます。

 

 

Kali Linuxの操作

 

Kali Linuxは、セキュリティ診断やペネトレーション・テストのためのツールです。このラボでは、Kaliを使用して、SDDCの172.16.0.0/16ネットワークに対し集中的なスキャンを実施します。

ここで見ていくのは問題のWebサーバ(IPアドレスは172.16.10.11)のみですが、データベース・サーバやアプリケーション・サーバにも別の問題が見つかるかもしれません。

Kaliにアクセスするため、vSphere Web Clientを起動して [VMs and Templates] をクリックします。

  1. [vcsa-01a.corp.local] を展開します。
  2. [Kali Linux] をクリックします。
  3. 黒いボックスをダブルクリックして、Kaliへのコンソール接続を開始します。

 

 

Kali Linux Live

 

Kali Linux Liveの画面が表示されます。

  1. 画面に上向きの矢印が表示されます。
  2. マウスをクリックし、そのまま矢印の方向に動かします。すると、Kali Linux Liveのログイン画面が表示されます。

 

 

Kali Linuxへのログイン

 

ラボの認証情報を使用してKali Linuxにログインします。

  1. ユーザ名: root
  2. パスワード: VMware1!
  3. [Next] をクリックします(すでにログインしている場合は [Unlock] をクリックします)。

 

 

Kali LinuxとZenmapを使用したトラフィックの生成

 

Kali Linuxのデスクトップが表示されます。

デスクトップ左側のアプリケーション・ダッシュボードにマウス・カーソルを合わせ、Zenmapのアプリケーション・アイコンを見つけます。

  1. Zenmapのアプリケーション・アイコンをクリックします。

 

 

Zenmapの操作

 

Zenmapのスキャン・ウィンドウが表示されます。

Zenmapは、セキュリティ監査やペネトレーション・テストに利用できる便利なツールです。

 

 

Zenmapのインテンス・スキャンの実行

 

ではここから、172.16.0.0/16ネットワークに対してインテンス・スキャンを実施します。

果たして、Webサーバに存在する脆弱性をIPSで検出できるでしょうか。

172.16.0.0は、次のVMネットワークで構成されています。

Zenmapの設定はすでに完了しています。

  1. Zenmapの [Target] ドロップダウン・メニューの矢印をクリックし、ターゲットとして [172.16.0.0/16] を選択します。
  2. [Profile] ドロップダウン・メニューの矢印をクリックし、プロファイルとして [Intense Scan] を選択します。
  3. [Services] タブをクリックします。
  4. [Scan] ボタンをクリックします。

スキャンが開始されます。

 

 

Zenmapの出力の表示

 

[Nmap Output] にスキャンの進捗状況が表示されるので、しばらく待機します。

 

 

Will You Find Shadow IT's FUBAR Web Server?  Investigate IPS Events in SmartLog!

 

シャドウITのWebサーバに存在する脆弱性を検出できるか。SmartLogでIPSイベントを調査

Zenmapでのインテンス・スキャンにより、チェック・ポイントのIPSエンジンで発生したイベントをSmartLogで調査します。

  1. SmartLogが起動していない場合は、メイン・コンソールのデスクトップから起動します。
  2. SmartLogを起動すると、コンソールが表示されます。
  3. SmartLogの検索フィールドをクリックし、[blade: IPS] と [time: Past Hour] を選択します。
  4. 検索フィールドの右側にある更新ボタンをクリックするか、F5キーを押します。

ZenmapでのスキャンによってIPSエンジンで発生したイベントが表示されます。この中に、Webサーバ172.16.10.11でのイベントは含まれているでしょうか。

次のステップでは、ログの詳細を調査します。

 

 

SmartLogの検索フィルタの適用:1時間以内に発生したIPSイベント

 

適用したカスタム検索フィルタに合致するログ・イベントが表示されます。

 

 

SmartLogでIPSイベント・ログの詳細を調査

 

  1. 「Web Server Enforcement Violation」に関係するログ・エントリをダブルクリックし、ログの詳細を表示します。

このウィンドウでは、ログ・エントリをさらに詳しく調べることができます。

この詳細ウィンドウでは、送信先と送信元のIPアドレスも確認できます。

 

 

保護機能の名称および属性へのハイパーリンク

 

このイベントのさらに詳しい情報や関連するIPS保護機能の詳細を確認してみましょう。

[General Event Information] セクションの [Protection Name] に表示されている保護機能名にはハイパーリンクが設定されています。

  1. このハイパーリンクをクリックすると、自動的にSmartDashboardが開き、保護機能の詳細が表示されます。

 

 

保護機能の詳細の表示

 

保護機能名のハイパーリンクをクリックすると、SmartDashboardの [Protection Details] ウィンドウが表示されます。

  1. この保護機能はRecommended Protectionプロファイルの検出アクションで動作しています。シグネチャ・ベースのサーバ向け保護機能であり、重要度は緊急(Critical Severity)、信頼度は高(High Confidence Level)、パフォーマンスへの影響は中程度(Medium Performance Impact)であることが確認できます。
  2. この画面では、保護機能の追跡調査([Follow Up])設定や、検出から防御へのアクションの変更([Change Action])、この保護機能で生成されたログの参照([View Logs])を行えます。
  3. 詳細を確認したら、[OK] をクリックして [Protection Details] ウィンドウを閉じます。

 

 

パケット・キャプチャを表示するハイパーリンク

 

再びSmartLogのIPSイベントの [Log Details] ウィンドウに戻り、さらに別の情報を参照します。

  1. [More] セクションには [View Packet Capture] というハイパーリンクがあります。
  2. このラボ・マシンのように、SmartLogを実行しているクライアント・マシンでWiresharkを実行している場合、リンクをクリックすると、IPS保護機能で生成されたパケット・キャプチャをWiresharkで表示できます。
  3. [View Packet Capture] リンクをクリックします。

 

 

ハイパーリンクをクリックし、Wiresharkでパケット・キャプチャを調査

 

SmartLogの [Log Details] ウィンドウで [View Packet Capture] リンクをクリックすると、Wiresharkでパケット・キャプチャが表示されます。

  1. 表示された画面で、このIPS保護機能に関連するパケット・キャプチャを調査できます。
  2. 調査が終了したら、Wiresharkを終了します。

以上で、IPSイベントの詳細を把握できたことになります。

このレッスンでは、次のことを学習しました。

このレッスンで実施したのは、サイバー・セキュリティの専門家にとってはごく日常的な作業です。

このモジュールでは、現実に即した問題を取り上げながら、さまざまなことを学習しました。大変お疲れ様でした。

 

まとめ


このモジュールでは、SDDCでは基本的なファイアウォールにとどまらず、多層防御の高度なセキュリティ対策が必要である理由について学習しました。アプリケーションとvSECおよびIPS保護機能を素早く展開する方法について十分な知識を得ると共に、チェック・ポイントのIPSが提供する、SDDCを内部のセキュリティ脅威から保護するためのインテリジェントな保護機能について学びました。


 

モジュール3の終了

 

以上で、モジュール3のレッスンはすべて終了しました。

Check Point vSECとNSXによるSDDCの保護について、さらに詳しく知りたい場合は、次のいずれかの方法で追加資料をご覧ください。

ご興味のある次のいずれかのモジュールにお進みください。

 

 

ラボの終了方法

 

ラボを終了するには、[END] ボタンをクリックします。

 

モジュール4 - ボットの検出、隔離、インシデント対応(30分)

はじめに


重要:ラボを初めて開始する際は、まずメイン・コンソールの [Lab Status] の表示を確認してください。[Lab Status] [READY] になっていたら、ラボを開始してください。[FAILED] の場合はいったんラボを終了し、新しいラボを開始してください。

このモジュールでは、ボットに感染したアプリケーションVMを検出、封じ込め、隔離する方法を学習します。Check Point vSECのアンチボット・エンジンは、ボットに感染して乗っ取られたSDDC内のアプリケーションVMを検出して隔離します。ボットに感染したVMがvSECによって検出および隔離される仕組み、ボット感染VMを封じ込めて隔離する事前定義済みのセキュリティ・ポリシー、SmartLogでのセキュリティ・イベントの通知、NSX Managerでの感染VMへのセキュリティ・タグ設定について学びます。

このモジュールで学習する主な内容は次のとおりです。

  1. ボット感染は、アンチウイルスでは検出、隔離できません。最近では、それほど高度ではないボットでも、自身の存在を隠蔽し、アンチウイルス・エンジンによる検出を回避する機能を備えています。
  2. SDDC環境の場合、感染VMを隔離できれば、復旧自体は容易に行うことができます。

ラボに関する注: このラボ環境は、すでにセットアップが完了しており、次の設定が行われています。

以降では、チェック・ポイントのアンチボット・エンジンとNSXのセキュリティ・タグの動作について学習します。


vSECの脅威対策タグの設定


Check Point vSECゲートウェイにより感染が確認されたVMは、自動的に周囲から切り離され、隔離されます。この機能は、Check Point vSECが感染VMにタグを設定し、その情報をVMware NSXコントローラと共有するという仕組みによって実現されています。

また、連携プラットフォームを使用すれば、復旧サービスを自動実行することもできます。これにより、感染拡大を直ちに封じ込め、感染VMに適切な復旧サービスを適用できます。

このレッスンでは、vSECとNSXの統合ソリューションにおける脅威対策タグの動作の仕組みについて学習します。


 

仕組み

 

  1. VMがマルウェアに感染
  2. VM上のマルウェアがC&Cサーバとの通信を試行
  3. vSECゲートウェイ上のAnti-Bot Software Bladeがこの通信を遮断し、感染VMのIPアドレスとタイプを含むタグ・コマンドをvSECコントローラに送信
  4. vSECコントローラが感染VMのIPアドレスをVMware vCenter Serverに送信
  5. VMware vCenter Serverが感染VMのVMware管理対象オブジェクト参照ID(MoRef ID)を返送
  6. vSECコントローラが感染VMのタイプとMoRef IDをVMware NSX Serverに送信
  7. VMware NSX Serverが適切なセキュリティ・タグを感染VMに追加

 

 

PuTTYを使用してvSECコントローラのService Managerメニューにアクセス

 

このステップでは、PuTTYを起動してvSECコントローラへのSSH接続を開始します。

  1. メイン・コンソールのデスクトップで、タスク・バーからPuTTYを起動します。
  2. [Saved Sessions] で [cpsmsvsec] をクリックします。
  3. [Load] をクリックします。
  4. [Open] をクリックします。

 

 

Security Managementサーバへのログイン

 

プロンプトが表示されたら、Security Managementサーバ/vSECコントローラのパスワードを入力します。

パスワードはVMware1!です。

Check Point Gaiaのコマンドラインが表示されます。

gw-01356b >

 

 

「vsec config」と入力してvSEC Service Managerメニューを表示

 

コマンドラインで次のように入力します。

vsec config

vSEC Service Managerメニューが表示されます。

 

 

オプション7 [Anti-Malware Configuration] を選択

 

vSEC Service Managerメニューで次の操作を行います。

  1. [Selected option:] で「7」と入力し、Enterキーを押します。
  2. [Anti-Malware Configuration] のサブメニューが表示されます。

 

 

オプション3を選択して設定済みのゲートウェイとクラスタを表示

 

[Anti-Malware Configuration] のサブメニューでオプション3を選択して、設定済みのゲートウェイとクラスタを表示します。

  1. [Selected option:] で「3」と入力し、Enterキーを押します。

 

 

アンチマルウェアが設定されたクラスタの表示

 

設定情報が表示されます。

  1. vsecsvm-RegionA01-RegionA01-COMP01というクラスタ名が表示されます。このクラスタはvSECクラスタです。
  2. nsxmgr-01a-corp.localというNSX名が表示されます。このNSXは、ここまで使用してきたNSX Managerです。
  3. vcsa-01a.corp.localというvCenter名が表示されます。このvCenterは、ここまで使用してきたvCenter Serverです。
  4. DATA_SECURITY.violationsFoundというアンチボット・タグ名も表示されています。モジュール2で学習したように、このタグはNSX Managerで定義します。

次の操作でこのメニューを終了します。

PuTTYセッションが終了します。

次に、NSX Managerの設定画面に移動し、この定義を再度確認してみましょう。

 

 

NSX Managerでのセキュリティ・タグの定義

 

vSphere Web Clientの [Networking & Security] ホームから、左側のパネルにある [NSX Managers] をクリックします。

次のステップで、[NSX Managers] をクリックして展開します。

 

 

NSX Managerオブジェクト

 

[NSX Managers] の [Objects] ウィンドウで、IPアドレスが192.168.110.15のNSX Managerをクリックします。

 

 

NSX Managerでのセキュリティ・タグの管理

 

NSX Manager 192.168.110.15を展開したら [Manage] タブをクリックし、[Security Tags] ボタンをクリックします。

NSX Managerで使用可能なセキュリティ・タグのリストが表示されます。

その中に、DATA_SECURITY.violationsFoundセキュリティ・タグ定義も表示されます。これは、先ほどvSEC Service Managerメニューで確認したセキュリティ・タグ定義です。

これで、vSECとNSX Managerの統合ソリューションで使用するセキュリティ・タグが定義されている場所を確認できました。

 

 

NSXセキュリティ・タグの作成、割り当て、割り当て解除

 

このウィンドウのコントロール・ボタンとセキュリティ・タグの一覧の間には、3つのアイコンが表示されています。各アイコンにマウス・カーソルを合わせると、アイコンの機能が表示されます。これらのアイコンを使用すると、次の操作を行えます。

 

セキュリティ・タグのテスト


VMwareの管理者やセキュリティ・チームは、vSphere Web ClientのNSX Manager設定画面を使用して、セキュリティ・タグの割り当てや割り当て解除を行えます。

セキュリティ・タグは、vSECの脅威対策タグを介して自動的に割り当てることもできます。


 

セキュリティ・タグの割り当て

 

VMwareの管理者やセキュリティ・チームは、vSphere Web ClientのNSX Manager設定画面を使用して、セキュリティ・タグの割り当てや割り当て解除を行えます。

セキュリティ・タグは、vSECの脅威対策タグを介して自動的に割り当てることもできます。

VMに感染したマルウェアが既知のC&Cサーバへの接続を試みたというシナリオを考えてみましょう。

次のステップでは、感染VMを周囲から切り離し、隔離するチェック・ポイントの高度な脅威対策セキュリティ・ポリシーのルールを確認していきます。

その前に、[DATA_SECURITY.violationsFound - Virtual Machines] ウィンドウを閉じておきます。

 

 

vSphere Web Clientの [VMs and Templates] への移動

 

[VMs and Templates] をクリックし、[app-01a-corp.local] をクリックします。

展開された状態の [VMs and Templates] ウィンドウが表示されます。

[app-01a.corp.local] をクリックして [Summary] タブをクリックし、このVMの概要を表示します。

VMの設定内容が表示されます。

[Security Tags] セクションで、このVMにDATA_SECURITY.violationsFoundセキュリティ・タグが割り当てられていることを確認できます。

[Security Groups Membership] セクションでは、app-01a.corp.localが次のセキュリティ・グループのメンバーになっていることを確認できます。

このVMは、どこでInfected VM Groupのメンバーとして定義されているのでしょうか。

モジュール2で学習したように、Infected VM Groupセキュリティ・グループはService Composerで定義されています。

では、このVMはチェック・ポイントのセキュリティ・ポリシー内でどのように扱われているのでしょうか。

次のステップでは、SmartDashboardを使用して、感染VMのセキュリティ・ポリシー・ルールを確認します。

なお、app-01a.corp.localのIPアドレスは172.16.20.11です。この後のレッスンで必要となりますので、覚えておいてください。

 

 

SmartDashboardでの感染VMの隔離

 

SmartDashboardが起動していない場合は、メイン・コンソールのデスクトップから起動します。

  1. [Firewall] タブをクリックします(このタブが選択されていない場合)。
  2. [Advanced Threat Prevention Scenarios] ルールベースを展開します。

感染VMを処理するためのルールが2つ定義されています。

つまり、DATA_SECURITY.violationsFoundというセキュリティ・タグと、感染VMであるという脅威対策タグが割り当てられたVMは、他のVMといずれの方向でも通信できず、他のVMも感染VMとは通信できないということです。

次のステップでは、感染VMであるapp-01a.corp.localへの通信を発生させ、そのトラフィックが破棄されたことをSmartLogで確認します。

 

 

vSphere Web Clientでweb-01a.corp.localに接続

 

vSphere Web Clientを開きます。

  1. [VMs and Templates] に移動します。
  2. [web-01a.corp.local] をクリックします。
  3. 黒いボックスをクリックし、web-01a.corp.localへのコンソール接続を開始します。

 

 

web-01a.corp.localへのログイン

 

ここでは、IPアドレス172.16.20.11のapp-01a.corp.localに向けてpingを実行します。

web-01a.corp.localへのコンソール接続が確立されたら、次の認証情報を使用してログインします。

ping 172.16.20.11  

pingの結果を確認してください。

Ctrlキーを押しながらCキーを押し、コンソールを終了します。

次のステップでは、SmartLogでログを調査します。

 

 

SmartDashboardからのSmartLogの起動

 

SmartDashboardからSmartLogを起動します。

  1. メニュー・バーの [SmartConsole] をクリックします。
  2. [SmartLog] をクリックします。

 

 

SmartLog

 

SmartLogが表示されたら、web-01a.corp.localからapp-01a.corp.localへの通信の試みを調査します。

  1. 検索フィールドをクリックし、[time:Past Hour] と [action:Drop] を選択します。すると、最近破棄された、web-01a.corp.localを送信元とする通信のログが表示されます。
  2. いずれかのログ・エントリをダブルクリックします。

 

 

SmartLogの詳細

 

SmartLogのログ・エントリをダブルクリックすると、[Log Details] ウィンドウが表示されます。

感染VMが隔離されている間に、新しいVMを開始して、元のVMが担っていた役割をシームレスに引き継ぐことができます。

 

Exploring the Incident Handling Process


In the previous lesson, you learned about vSEC Threat Prevention tagging integration with VMware NSX security tagging.  This capability is a key differentiator for Check Point and VMware.  

  1. If you are a cyber security warrior, you understand that security totally ROCKS especially if it can be part of the service chain -- part of the ICT services delivery workload in the SDDC.  
  2. Agility and the ability to deliver Quality of Experience ICT services (not just applications) to DRIVE business for your organization,  your business partners, and your customers in the way these entities need and want to consume these services -- this is what the SDDC brings.  And in the SDDC, security has to be an integral part of the solution.  
  3. We live in a world of DEVOPs and with this forces the unification of previous silos of operations. No longer can security be a stand alone process, be perceived as "the people who say no" or represent a bottleneck to the speed of business.  Security is not a trade off to agility and now you might even consider challenging status quo thinking and champion security as a top line business driver.
  4. In fact, the SDDC brings to the security suite a realized dream -- the potential for security to be automated and orchestrated along with an entire service chain -- rapidly delivering QoE ICT services that are secure. This is the dream of the cyber security warrior, this concept of building security in.  

 

Concept of IR/IH in Your SDDC?

Think through how you handle IH/IR within your organization and how you can leverage vSEC Threat Prevention and NSX security tagging for real time containment of security events, and automation to protect the availability and uptime of critical ICT applications and services.  

You may not have all of the answers today -- now that you know how this can work, you can knowledge transfer this back to your organization.

 

 

Security Incident Processes in the Enterprise

Incident handling (IH)/incident response (IR) is a typically a key function of the security suite in the enterprise.

IH/IR typically has to weigh the situation: how to effectively investigate security incidents  in the SDDC without dramatically interrupting the business.  

IH/IR has to weight risk, reward, tradeoff given the situation presented:

In the VMware SDDC with NSX and Check Point vSEC, security tagging provides an effective way of automating containment of security incidents using Check Point's Advanced Threat Prevention, without reducing service levels or impacting business, and all the while leveraging the power of VMware SDDC vSphere, vCloud, and vRealize automation and orchestration suite to protect critical applications from any reduction in service.  

And the IH/IR team gets what it wants: ability to control the situation and reduce risk to the business.  

 

 

IR/IH Managed Infected VM Decision Point

Where we left off from the previous lesson: we have this infected VM (app-01a.corp.local) and this VM has been automatically isolated and contained (quarantined) based on the Check Point predefined security policy for infected VMs.  

In our lab, and in this hypothetical VMware SDDC environment, we have already spun up a clean version and inplaced this VM into service to take over for the compromised application server (app-01a.corp.local).  We will call this new application server app-02a.corp.local.  

This new web server is dynamically added to the App Security Group, and therefore, this new app server is immediately protected by vSEC based on the App Security Group security policy.   No policy push is necessary.  

For your organization, the next step to manage this infected VM to comes to a decision point:

  1. Take time to investigate perform CSI on the Infected VM to identify the nature of the infection and have your malware engineers reverse engine the compromise
  2. Clean, patch or otherwise remediate the infected VM and return to service
  3. Leave the compromised server in isolation in case need for future investigation
  4. Kill the compromised web server

How your organization will want to manage this Infected VM will be based on your organizational policy and procedures, IR/IH team competencies, DEVOPS "pets versus cattle" philosophy, and the nature of the actual compromise.  You can do all of the above, while maintaining availability of your ICT services.  

 

 

Remove Infected VM Security Tag

 

For the purposes of our lab, you will go through the process of removing the Infected VM security tag.

You will see that when you do, app-01a.corp.local will be automatically placed back in service do to the integration of vSEC with NSX. There is no need to change anything in the security policy.  

 

 

Security Tag >> Manage

 

From where you are, mouse over the Manage hyperlink in the Security Tags box.  You see this is link to manage.

  1. Click Manage and you are presented with app-01a.corp.local - Assign Security tag to Virtual Machines window.
  2. You see the check box is selected (checked on) for DATA_SECURITYviolationsFound.

 

 

Deselect Security Tag

 

  1. Click on the check box to deselect (check off) the DATA_SECURITYviolationsFound tag.  
  2. Then click OK.

You will see a message Security Tag updated.

 

 

Verify app-01a.corp.local is Removed From Infected VMs Security Group

 

You see this confirmation in the Security Tags and Security Group Membership boxes respectively.  

 

 

Confirm app-01a.corp.local is No Longer Isolated

 

From vSphere Web Client, open a console connection to web-01a.corp.local.

When the console is presented to you issue an ICMP ping request to app-01a.corp.local at its IP address 172.16.30.11

From command line type

ping 172.16.30.11

What is the result?  

The application server app-01a.corp.local is no longer isolated and is back in service.  

 

Conclusion


After taking this module, you understand how the Check Point VSEC Anti-Bot engine works with VMware NSX integration, how security tagging works, and have confidence in Check Point Anti-Bot engine to detect, isolate, contain, and quarantine a bot compromised VM, and the power of VSEC and NSX Manager integration -- VSEC updates NSX Manager of the bot incident and with the compromised VM “infected VM” tag.  The compromised application VM is quarantined, no traffic to or from this compromised VM is permitted, and remediation of the compromised application VM is now made easy.


 

You've finished Module 4

 

Congratulations on completing Module 4.

If you are looking for additional information on Securing the SDDC with Check Point vSEC and NSX, try one of these:

Proceed to any module below which interests you most. 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 5 - Deeper Dive and Troubleshooting (30 minutes)

Introduction


IMPORTANT NOTE: When you first begin the lab, be sure to check the Lab Status indication on the Main Console.  If Lab Status shows READY, start the lab.  If the Lab Status shows FAILED, then end the lab and start a new lab.  

In this module you will get a deeper dive into technical details regarding Check Point vSEC with VMware NSX integration.

The integration of Check Point vSEC with VMware NSX brings together the best of both worlds - advanced security protection dynamically deployed and orchestrated into a Software-Defined Data Center environment:

Comprehensive Threat Prevention -- industry-leading threat prevention security to keep data centers protected from lateral movement of threats and the most sophisticated attacks. Fully integrated multi-layer security protections include:

Ubiquitous Security Enforcement -- Check Point vSEC integration with VMware NSX allows dynamic insertion of advanced security protection between workloads enabling distributed enforcement at every virtual interface. The integration automates and simplifies the provisioning of vSEC Gateways into the NSX virtual fabric to protect East-West traffic from lateral movement of threats enabling feasible micro-segmentation.

Auto-Quarantine of Infected Virtual Machines -- Virtual Machines identified by Check Point vSEC Gateway as infected, can be automatically isolated and quarantined. This is accomplished by Check Point vSEC tagging the infected virtual machines and sharing this information with the VMware NSX Controller. Additionally, automated remediation services can be triggered by an orchestration platform. Threats are quickly contained and the appropriate remediation service can be applied to the infected VM.

Context-Aware Security Policies -- The integration with VMware NSX Controller and VMware vCenter shares context with the Check Point vSEC Controller, allowing security groups and VM identities to be imported and reused within Check Point security policies. This reduces security policy creation time from minutes to seconds. Real-time context sharing of security groups is maintained, so that any changes or new additions are automatically tracked without the need for administrator intervention. Security protections are dynamically applied to newly created applications regardless of where they are hosted.

Complete Visibility and Control -- vSEC for VMware NSX provides consolidated logging and reporting of threats and security events. Check Point logs are further enriched with NSX context including security group tags. Additionally, the Check Point SmartEvent platform provides advanced incident tracking and threat analysis across both the physical and virtual data-center network traffic.

Centralized and Unified Management -- Security management is simplified with centralized configuration and monitoring of vSEC. Traffic is logged and can be easily viewed within the same dashboard as other gateways. Security reports can be generated to track security compliance across the data center network. A layered approach to policy management allows administrators to segment a single policy into sub-policies for customized protections and delegation of duties per application or segment.


Understanding Integration Components and Flows


In this lesson you will learn more about the Check Point vSEC with VMware NSX integration, how it works, vSEC traffic flow, helpful to know daemons, files, and databases.


 

vSEC Controller and vSEC Gateway Service Virtual Machine (SVM)

Check Point vSEC Controller - The Security Management Server / Multi-Domain Security Management Server capable of managing Check Point vSEC Gateways. Makes the Check Point Security Management Server dynamically data center aware with VMware NSX and VMware vCenter Server integration. This lets vSEC Controller make dynamic security policies, manage vSEC Gateways and physical gateways, and provides complete visibility for data center security. vSEC is based on the VMware Network Extensibility (NetX) API.

Check Point vSEC Gateway - The Service Virtual Machine (SVM) in the VMware virtual environment. Inspects all traffic that goes to, from, or inside the protected Security Group. It leverages the VMware NSX API for traffic redirection and inspection, securing traffic between virtual machines across the virtual network without altering the network topology. Secures data center traffic between virtual machines across the virtual network.  vSEC Gateway is deployed on each VMware ESXi cluster member and integrated into VMware NSX.

Check Point vSEC Cluster - Two or more vSEC Gateways synchronized for High Availability or Load Sharing.

Check Point vSEC Service Manager - vSEC component. Deploys and manages the service communication between Check Point products and the VMware NSX through VMware REST API.

 

 

vSEC Under the Hood

 

vSEC Gateway inspects all traffic that is directed to and from, or within the protected Security Group  (NSX Security Group).

Components:

  1. VMware ESX host includes multiple ESXi hosts in an ESXi cluster make the physical infrastructure.
  2. VMware NSX Manager defines Security Groups and redirection policy.  From VMware NSX Manager, vSEC Controller learns Security Groups.
  3. VMware vCenter Server manages ESXi hosts.  From VMware vCenter, vSEC Controller learns vCenter inventory: VMs, ESX/ESXi Clusters, vApps, Resource Pool, Data Centers, Hosts, and Cluster Folder.
  4. Check Point vSEC Gateway Service VM inspects traffic between VMs in the Security Group, and traffic coming in and going out of the Security Group.
  5. Inspected Virtual Machines.
  6. Protected Security Groups are collections of objects from the vSphere inventory, protected by NSX.
  7. SDDC core includes switching and routing infrastructure of the SDDC.
  8. Check Point Physical Security Gateway is supported for North-South physical appliance for inspection and enforcement.
  9. Check Point vSEC Controller is the Software-Defined Data Center (SDDC) aware Check Point Security Management Server.  vSEC Controller works with one (1) VMware NSX manager and one (1) VMware vCenter Server.  

Notes:  

 

 

vSEC Specific Daemons and Files

 

  1. SmartDashboard (on SmartConsole Client) connects to FWM daemon on vSEC Controller.
  2. FWM daemon connects to CMS_PROXY daemon.
  3. CMS_PROXY daemon connects to VMware NSX / vCenter:
  1. VMware objects are manually added by the administrator to rules.  VMware objects are saved as virtual objects in the $FWDIR/database/virtual_objects.db file on vSEC Controller.
  2. FWM daemon installs the policy on the vSEC Gateway.  VMware objects are saved as virtual objects in the $FWDIR/database/virtual_objects.db file on vSEC Gateway.  Relevant kernel tables are updated on vSEC Gateway.
  3. On vSEC Controller, FWCLOUD daemon "asks" the CMS_PROXY daemon (web service request) to fetch all involved VMware objects from VMware NSX / vCenter every 30 seconds (default).  Note: Check Point log is generated only if this connection fails.  CMS_PROXY daemon parses the XML file (maps VMware objects and their IP addresses) and sends the relevant information to FWCLOUD daemon.  Note: There are no logs or history for which objects were fetched.  VMware objects are saved as virtual objects in the $FWDIR/database/virtual_objects.db file on vSEC Controller.
  4. vSEC Controller decides if the $FWDIR/database/virtual_objects.db file on vSEC Gateway has to be updated:

 

 

Walk Through vSEC Traffic Flow

Traffic Flow in ESX/ESXi server with deployed vSEC Gateway.

  1. Packet is generated on VM #1 to be sent to VM #2.
  2. Packet is intercepted by VMware DFW.
  3. According to the configured VMware redirection policy, the packet is redirected to the vSEC Gateway for inspection.
  4. Packet appears in the shared memory of VMware dvfilterklib library.
  5. Secure Network Dispatcher (SND) thread within the FWK daemon gets a notification using the NetX API about the packet sent to the vSEC Gateway.
  6. Packet is sent to the global CoreXL FW instance by the SND, and a decision function is called to decide which CoreXL FW instance should handle this packet according to the 5-tuple (Source_IP, Source_Port, Dest_IP, Dest_Port, Proto).
  7. Packet is inspected by the selected CoreXL FW instance.
  8. Packet is accelerated by SecureXL, if acceleration is possible/needed.
  9. SND thread thread within the FWK daemon thread within the FWK daemon gets a notification using the NetX API that a packet needs to be sent out of the vSEC Gateway.
  10. Packet appears in the shared memory of VMware dvfilterklib library.
  11. Packet continues down its original path from VM #1 to VM #2.
  12. When packet arrives at VM #2, it is redirected to the vSEC Gateway for inspection.

Helpful Notes:  

If traffic is redirected to the vSEC Gateway, without any policies configured on the vSEC Gateway, then the traffic will pass according to Failure Policy that was defined by the vSEC administrator:

 

 

Traffic actually comes from the User Mode NetX API into Check Point's user mode FWK daemon.

 

 

Traffic flows in the following way

 

 

vMotion and traffic handling

 

 

vSEC Databases

vSEC Gateway

vSEC Controller

 

 

vSEC Gateway Logs

vSEC Gateway logs are based on the Identity Awareness infrastructure.  In R77.30 vSEC Gateway, Identity Awareness must be enabled to see any traffic logs.  With vSEC Gateway, the Identity Awareness is included.

Check Point log for matched rule will show the Name of Check Point Data Center Group (name of virtual object).  

Log example:

 

Insight into vSEC Processes


This lesson provides you will valuable insight regarding the main Check Point vSEC Controller processes and tips for troubleshooting.  

The goal here is to arm you with additional knowledge that will help you troubleshoot: critical processes, what each process does, process interactions, check whether process is running, along with some basic level debugging and the relevant log file to be investigated.

Important source information for this lesson comes from the Check Point Advanced Technical Resource Guide vSEC for VMware NSX (ATRG: vSEC for VMware NSX), solution ID sk111060.  All credit goes to the authors of this ATRG.  

For brevity sake in this lab, only the most essential information is provided within this module.  To obtain the full ATRG: vSEC for VMware NSX, solution ID sk111060, please visit Check Point's Secure Knowledge Base.

For extended details regarding all of Check Point processes, please refer to Check Point Secure Knowledge article, solution ID sk97638, titled Check Point Processes and Daemons.  


 

vSEC Controller Process FWM

What does FWM do?

Useful Information:

  1. Path: $FWDIR/bin/fwm
  2. Log file location: $FWDIR/log/fwm.elg

Commands:

  1. To Stop: [Expert@HostName:0]# cpwd_admin stop -name FWM -path "$FWDIR/bin/fw" -command "fw kill fwm"
  2. To Start: [Expert@HostName:0]# cpwd_admin start -name FWM -path "$FWDIR/bin/fwm" -command "fwm"
  3. Stat Process: [Expert@HostName:0]# cpwd_admin list  
  4. Stat Process: [Expert@HostName:0]#  ps auxw

Notes:

 

 

vSEC Controller Process CMS_PROXY

What does CMS_PROXY do?  

Useful Information:

  1. Path: $FWDIR/jre/bin/java loads files from $FWDIR/lib/Arcus/
  2. Log file location: $FWDIR/log/cloud_proxy.elg

Commands:

  1. To Stop: [Expert@HostName:0]# arcus_proxy_stop
  2. To Start: [Expert@HostName:0]# arcus_proxy_start

Notes:

 

 

vSEC Controller Process FWCLOUD

What does FWCLOUD do?

Useful Information:

  1. Path: $FWDIR/bin/fwcloud
  2. Log file: $FWDIR/log/fwcloud.elg

Commands:

  1. To see the current poll time: [Expert@HostName:0]# cpd_sched_config print
  2. To Stop: [Expert@HostName:0]# arcus_proxy_stop
  3. To Stop: [Expert@HostName:0]# cpwd_admin stop -name FWCLOUD
  4. To Start:[Expert@HostName:0]# arcus_proxy_start
  5. On Security Management Server: [Expert@HostName:0]# cpwd_admin start -name FWCLOUD -path $FWDIR/bin/arcus_proxy_start -command "arcus_proxy_start"
  6. On Multi-Domain Security Management Server: [Expert@HostName:0]# cpwd_admin start -name FWCLOUD -path $MDS_TEMPLATE/bin/arcus_proxy_start -command "arcus_proxy_start"

Notes:

 

 

vSEC Controller Process FWCLTAG

What does FWCLTAG do?

Useful Information:

  1. Path: $FWDIR/jre/bin/java loads files from $FWDIR/lib/Arcus/
  2. Log file: $FWDIR/log/cloud_tagger.elg

Commands:

  1. To Stop: [Expert@HostName:0]# arcus_proxy_stop
  2. To Stop: [Expert@HostName:0]# cpwd_admin stop -name FWCLTAG
  3. To Start: [Expert@HostName:0]# arcus_tagger_start
  4. To Start on Security Management Server: [Expert@HostName:0]# cpwd_admin start -name FWCLTAG -path $FWDIR/bin/arcus_tagger_start -command "arcus_tagger_start"
  5. To Start on Multi-Domain Security Management Server: [Expert@HostName:0]# cpwd_admin start -name FWCLTAG -path $MDS_TEMPLATE/bin/arcus_tagger_start -command "arcus_tagger_start"

Notes:

 

 

vSEC Controller Process CPVED

What does CPVED do?

Useful Information:

  1. Path: $FWDIR/bin/cpved
  2. Log file: $FWDIR/log/CPVED.elg

Commands:

  1. To Stop: [Expert@HostName:0]# cpved stop
  2. To Start: [Expert@HostName:0]# cpved start

Notes:

 

 

vSEC Controller Process VSEC

What does VSEC do?

Useful Information:

  1. Path: $FWDIR/bin/vsec
  2. Log file: None

Commands:

  1. Debug:  

Notes:

 

 

vSEC Process VSEC_CONFIG

What does VSEC_CONFIG do?

Useful Information:

  1. Path: $FWDIR/bin/vsec_config
  2. Log file: $FWDIR/log/vsec_config.elg

Notes:

 

 

vSEC Gateway Process FWK

What does FWK do?

Check Point FireWall kernel in User Space.

  1. Path: $FWDIR/bin/fwk
  2. Log file: $FWDIR/log/fwk.elg

Commands:

  1. To Stop: [Expert@HostName:0]# cpstop
  2. To Start: [Expert@HostName:0]# cpstart
  3. Debug:  

Notes:

 

 

vSEC Gateway Process VEM

What does VEM do?

Useful Information:

  1. Path: $FWDIR/bin/vem
  2. Log file: $FWDIR/log/vem.elg

Commands:

  1. To update the PDPD daemon with the current IP addresses of virtual objects:[Expert@HostName:0]# vem update
  2. Debug:

 

 

vSEC Gateway Process VEMD

What does VEMD do?

Useful Information:

  1. Path: $FWDIR/bin/vemd
  2. Log file: $FWDIR/log/vemd.elg

Commands:

  1. Debug:

 

vSEC Troubleshooting 101


In this lesson, you will learn how to perform "systems check" on vSEC integration to determine normal baseline where all systems have green light.  

Learning these basic troubleshooting steps will serve to arm you with knowledge that will greatly aid your ability to troubleshoot your own vSEC integration with NSX environments. Not knowing how to triage systems always makes things seem complex.  Knowing how to triage streamlines troubleshooting time and serves to reduce complexity.  

In this VMware vSEC Hands On Lab, you are testing in a pain free lab environment.  

CAVEAT:  As always, the small print (or rather) BIG PRINT here is this:  in PROD environment, be sure you are working with your Check Point and VMware technical support partners before doing anything more advanced than performing basic systems checks.  If you do not fully understand the implications of turning on a specific debug function, or performing testing on live and mission critical systems, do not do so without the advise of your technical support partners.  

Now let's roll!


 

vSEC Config Menu

 

Now you will verify vSEC connectivity NSX Manager using the vsec_config menu from Check Point Security Management Server / vSEC Controller.

  1. From Main Console task bar, launch instance of PuTTY.  
  2. From Saved Sessions, click on cpsmsvsec
  3. Click Load
  4. Click Open

 

 

Log in to Check Point Security Management Server

 

User name: admin

Password: VMware1!

 

 

Start vSEC Service Manager Menu vsec_config

 

At command prompt type:

gw-01356b> vsec_config

press Enter

 

 

The vSEC Service Manager Menu is presented to you.

 

 

 

From the vSEC Service Manager Menu you will check connection to NSX Manager

 

From Selection option: type 6 and press Enter.

 

 

You are presented with the NSX Managers already configured in SmartDashboard.  

 

From Selected option: type 1 and press Enter

 

 

You now receive confirmation, the connection to NSX Manager is established.  

 

 

 

Next you will check to see if the vSEC service is registered with NSX Manager.

 

To check this in the vSEC Service Manager Menu, you will use option 4 to show services.

From Selected option: type 4 and press Enter.

 

 

You are presented again the NSX Manager configured in Smart Dashboard.

 

From Selected option: type 1 and press Enter.

 

 

You are presented with Service Name: vsecsvm and Failure Policy: Fail-Open.

 

This message confirms the vsecsvm service (vSEC Gateway Service Virtual Machine) is registered to NSX Manager nsxmgr-01a.corp.local and the vSEC Gateway service is set to fail open.  

 

 

Exit the vSEC Service Manager Menu

 

You will exit the vSEC Service Manager Menu.

From Selected option: type 8 and press Enter.

You are back at the Gaia command line.

Minimize PuTTY session.

 

 

Verifying vSEC from NSX

 

From Main Console, click on Chrome.  This will launch vSphere Web Client.

From vSphere Web Client, click on Networking & Security.

 

 

Click on Installation

 

If not already on the Management tab, the click Management tab.

You observe NSX Manager, IP address 192.168.110.15 is Primary NSX Manager and is managed by its respective vCenter Server.

You have just verified NSX Manager is connected and available.

 

 

Service Deployment tab

 

Continue working from vSphere Web Client.

From Installation tab, click on Service Deployment tab.

Here you will see the vsecsvm service installation status is Succeeded and Service Status is Up.

If there is a problem with the vSEC Service, the service status will be down or have a caution sign next to it.

Service Status Down is typically indicative of a communication problem.

Service Status with Caution is typically indicative of a SIC problem.

 

 

View vSEC Debug Log

 

Open PuTTY session to Check Point Security Management Server / vSEC Controller.

Log in with credentials:

Go expert mode:

gw-01356b> expert

Enter expert password

Enter expert password: VMware1!

View the vsec_config log file.

Path: $FWDIR/log/vsec_config.elg

From command line type:

[Expert@gw-01356b:0]#  cat $FWDIR/log/vsec_config.elg

 

 

View the vsec_config log file

 

These are the configuration settings that were defined when building vSEC out from the vSEC Service Manager (vSEC Controller).

Note: you now see: NSX Manager and vCenter DNS names, Anti-Bot tagging enabled, vSEC SVM cluster, the vSEC Gateway instance names and IP addresses, the VMware ESXi cluster where the vSEC SVM is deployed, etc.

 

 

Confirm Availability of the vSEC SVM OVF Template

 

Check availability of the vSEC SVM OVF.  

Path to this template: # /opt/cpsuite-R77/VE/jetty/ve

The Security_R77_30VSEC.ovf template is used for vSEC SVM in NSX Service Deployment.  If the template is not available, the service deployment will fail.

Open Chrome browser tab and enter https://192.168.110.112:8443/ve/Security_Gateway_R77_30VSEC.ovf

You have now confirmed the vSEC Gateway SVM OVF template is available.  

 

 

Verify FWK Daemon is Running on Check Point vSEC SVM Instances

 

Do this from the vSEC Gateway Instance!

From command line type:

[Expert@gw-01356b:0]#  cpwd_admin list | grep -E "APP|FWK"

You will see the FWK is running.  The E in the STAT column indicates this daemon is executing.

 

 

Debug FWK

 

On vSEC Gateway, run the debug of FWK daemon:

Start the debug:

  1. [Expert@HostName:0]# fw ctl set int fw_kdprintf_limit 0
  2. [Expert@HostName:0]# fw debug fwk on TDERROR_FWK_VE=4
  3. Replicate the issue with the traffic.

Stop the debug:

  1. [Expert@HostName:0]# fw debug fwk off
  2. [Expert@HostName:0]# fw ctl set int fw_kdprintf_limit 60

On vSEC Gateway instance, analyze the $FWDIR/log/fwk.elg file.

 

 

Check Point virtD Tool from vSEC SVM Instances (vSEC Gateways)

What does the Check Point VIRTD_TOOL do?

Useful Information:

  1. Path: $FWDIR/bin/virtd_tool
  2. Log file: None

Notes:

Syntax: [Expert@HostName:0]# virtd_tool [-fwk_filters | -notify_state | -inspect_netx]  

where:  Arguments

Controls how FWK daemon treats the NetX traffic:

  1. Debug
  2. Start the screen capture: [Expert@HostName:0]# script /var/log/debug_of_virtd_tool.txt
  3. Execute the command under Check Point debug: [Expert@HostName:0]# TDERROR_ALL_ALL=5 virtd_tool [argument]
  4. When you see the Expert mode prompt, press CTRL+D keys
  5. Analyze /var/log/debug_of_virtd_tool.txt

 

 

Run virtd_tool from vSEC SVM Instances (vSEC Gateways)

 

To verify the vsec agent is linked to the dvfilters of your protected VMs will will run the virtd_tool -fwk_filters.

Let's test the virtd_tool.

Now open PuTTY and from Saved Sessions select vsecsvm(1), click load, click open.

Log into vsecsvm(1) serviceinstance-10-ae8818 with the credentials:

Go expert mode:

serviceinstance-10-ae8818> expert

Enter expert password: VMware1!

From command line type:

[Expert@serviceinstance-10-ae8818:0]#  cd $FWDIR/bin

[Expert@serviceinstance-10-ae8818:0]#  virtd_tool

You are presented with the virtd_tool usage instructions.

 

 

virtd_tool >> Print Filters

 

Now you will print all the filters known to the fwk.

From command line, type

[Expert@serviceinstance-10-ae8818:0]#  virtd_tools -fwk_filters

press Enter

You are presented with 1 known filters:

You see the filter name, Vm UUID, Policy is Inspect.  

Now do the same for your other vSEC Gateway instance.  PuTTY Saved Session is vsecsvm(2).

 

 

tcpdump

A note about the interfaces on the vSEC Gateways!!

You can run tcpdump just to confirm there is traffic on eth0 (management interface) and no traffic on eth2 (production interface).  eth2 should report as listening.  

From the command line type:

[Expert@serviceinstance-10-ae8818:0]#  tcpdump -i eth0 (management interface)

[Expert@serviceinstance-10-ae8818:0]#  CTRL+C (to stop)

[Expert@serviceinstance-10-ae8818:0]#  tcpdump -i eth2 (production interface)

[Expert@serviceinstance-10-ae8818:0]#  CTRL+C (to stop)

 

 

FW Monitor

Run FW monitor

[Expert@serviceinstance-10-ae8818:0]#  fw monitor -e 'accept host (10.0.0.201);'

 

 

Checking dvfilter Errors

 

On vSEC Gateway, verify that NetX slow path agent is registered:

[Expert@serviceinstance-10-ae8818:0]#  dmesg | grep "DVFilter connected"

Output should show: DVFilter connected

[Expert@serviceinstance-10-ae8818:0]# grep fwve_dvfilter_init $FWDIR/log/fwk.elg

Output should show:

fwve_dvfilter_init: succeeded

[Expert@serviceinstance-10-ae8818:0]#  lsmod | grep dvfilterklib

Output should show:

dvfilterklib        55812    1

vmci                128256   2 dvfilterklib,vsock

 

 

ESXi Host Troubleshooting Helpers

These commands are run from the ESXi Host and can be helpful for troubleshooting.

You must connect to the ESXi Host via SSH.

 

 

ESXi Host >> get list of filters

 

On ESXi host, get the list of filters:

[root@esx-01a:~] vsipioctl getfilters

 

 

ESXi Host >> rules for specific filter

 

On ESXi host, get the list of rules for specific filter:

[root@esx-01a:~] vsipioctl getrules -f <Filter Name>

 

 

ESXi Host >> get contents of specific container

 

On ESXi host, get the contents of specific container:

[root@esx-01a:~] vsipioctl getaddrsets -f <Filter Name>

 

 

ESXi Host >> get filter stats

 

On ESXi host, get the filter statistics:

[root@esx-01a:~] vsipioctl getfilters -a vmware-sfw -s

 

 

ESXi Host >> summarize-dvfilter part 1

 

Shows specific dvfilter.

From ESXi host command line (via SSH connection):

[root@esxi-01a:~]  summarize-dvfilter

 

 

ESXi Host >> summarize-dvfilter part 2

 

Shows specific dvfilter.

From ESXi host command line (via SSH connection):

[root@esxi-01a:~]  summarize-dvfilter

 

 

NSX Manager

You run these commands from the NSX Manager.

You must connect to the NSX Manager via SSH.

 

 

NSX Manager >> show dfw cluster all

 

With this command, you can get the Cluster Id which you can then further investigate.

From NSX Manager command line (via SSH connection):

nsxmgr-01a.corp.local>  show dfw cluster all

 

 

NSX Manager >> show dfw cluster domain-c85 (cluster: RegionA01-COMP01)

 

With this command, you can get the Cluster Id which you can then further investigate.

From NSX Manager command line (via SSH connection):

nsxmgr-01a.corp.local>  show dfw cluster domain-c85

 

 

NSX Manager >> show dfw host host-63

 

Shows DFW by host.  With this information, you can further investigate the dfw bound to each VM by VM Id.

Note: you see the following VMs attached to esx-01a.corp.local (host-63).

From NSX Manager command line (via SSH connection):

nsxmgr-01a.corp.local>  show dfw host host-63

 

 

NSX Manager >> show dfw host host-68

 

Shows DFW by host.  With this information, you can further investigate the dfw bound to each VM by VM Id.

Note: you see the following VMs attached to esx-02a.corp.local (host-68).

From NSX Manager command line (via SSH connection):

nsxmgr-01a.corp.local>  show dfw host host-68

 

 

NSX Manager >> show dfw vm vm-223

 

This command shows you the binding of the vsecsvm to ESXi host vNICs.  

This is vsecsvm(1) instance.

From NSX Manager command line (via SSH connection):

nsxmgr-01a.corp.local>  show dfw vm vm-223

 

 

NSX Manager >> show dfw vm vm-225

 

This command shows you the dvfilter binding to the vsecvm(2) vNICs.  

This is vsecsvm(2) instance.

From NSX Manager command line (via SSH connection):

nsxmgr-01a.corp.local>  show dfw vm vm-225

 

 

NSX Manager >> show dfw vm vm-72

 

This command shows you the dvfilter binding to the web-01a.corp.local vNICs.  

This is web-01a.corp.local instance.

From NSX Manager command line (via SSH connection):

nsxmgr-01a.corp.local>  show dfw vm vm-72

You can perform this to find bindings to any VM.

 

 

Helpful VMware Logs

ESX Agent Manager (EAM) log on vCenter Server

/storage/log/vmware/vpx/eam.log

ESXi Host:

/var/log/messages

ESXi Host:

/var/log/vsfwd.log

/var/log/vmkernel.log

/var/log/dfwpktlogs.log

 

Conclusion


After taking this module you have a much deeper understanding into the technical details of the vSEC with NSX integration components.  You have learned about vSEC works "under the hood", received deeper understanding vSEC specific daemons and files, and gained some real world, hands-on vSEC troubleshooting skills that greatly contribute to your confidence and ability to contribute and manage your Check Point vSEC with VMware NSX deployment.  

You have now achieved cyber security warrior status!  Congratulations!


 

You've finished Module 5

 

Congratulations on completing Module 5.

If you are looking for additional information on Securing the SDDC with Check Point vSEC and NSX, try one of these:

Proceed to any module below which interests you most. 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1724-SDC-1-JA

Version: 20170118-141219