サービス セキュリティ ダッシュボード
サービス セキュリティ ダッシュボードでは、すべての Cisco Service Control Application for Broadband(SCA BB)セキュリティ機能を表示して制御できます。
サービス セキュリティ ダッシュボードは、ワーム、Distributed Denial of Service(DDoS; 分散型サービス拒絶)攻撃、スパム ゾンビなどのセキュリティの脅威からネットワークを保護する一連の機能へのゲートウェイです。検出メカニズム(攻撃のしきい値など)、および攻撃が検出されたときに実行する処理も設定できます。
サービス セキュリティ ダッシュボードでは、Reporter ツールの悪質トラフィック レポートにアクセスすることもできます。
注意 悪質トラフィックの異常ベース検出が有効の場合、プラットフォームにサービス コンフィギュレーションを適用すると、Service Control Engine(SCE)プラットフォームで設定されているものの、インターフェイス、アクセス マップ、または Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)コミュニティ ストリングなどいずれにも適用されていない任意の Access Control List(ACL; アクセス コントロール リスト)が削除されることがあります。
回避策:
悪質トラフィックの異常ベース検出を無効にします ([Enable anomaly detection]
チェックボックスをオフにします)。
• 「サービス セキュリティ ダッシュボードの表示」
• 「ワーム検出の管理」
• 「異常検出の管理」
• 「スパム検出の管理」
• 「悪質トラフィックに関するレポートの表示」
サービス セキュリティ ダッシュボードの表示
ステップ 1 [Network Traffic] タブで [Service Security] を選択します。
ステップ 2 サービス セキュリティ ダッシュボードが右側ペインに表示されます(図 10-1)。
図 10-1 サービス セキュリティ ダッシュボード
ワーム検出の管理
SCA BB では、ワームの検出に次の 3 つのメカニズムが使用されます。
• シグニチャ ベース検出:SCE プラットフォームのステートフル レイヤ 7 機能では、その他のメカニズムで容易に検出できない悪質アクティビティを検出できます。新しいワームのシグニチャを追加できます。
• 異常ベース検出:全体的なトラフィック分析により、ワーム アクティビティを示す可能性のある異常を検出できます。「異常検出の管理」を参照してください。
• 大量メール送信ベース検出:E メール トラフィック分析により、E メールベース ワームを示すことがある異常を検出できます。「スパム検出の設定」を参照してください。
サポートされるワーム シグニチャの表示
ステップ 1 サービス セキュリティ ダッシュボードで [View Signatures] をクリックします。
[Signature Type] ドロップダウン リストで [Worm Signatures] が選択された状態で [Signatures Settings] ダイアログボックスが表示されます。
サポートされているすべてのワーム シグニチャがリストされます。
ステップ 2 [Close] をクリックします。
[Signature Settings] ダイアログボックスが閉じます。
サービス コンフィギュレーションへの新規ワーム シグニチャの追加
シスコが提供する最新の Digital Signature Standard(DSS; デジタル シグニチャ規格)ファイルまたは SPQI ファイルをインポートするか、サービス コンフィギュレーションに追加する任意のワーム シグニチャが含まれる DSS ファイルを作成します。
異常検出
異常検出の基本原理は、システムが確認するすべての IP アドレスとの正常接続レート(Transmission Control Protocol(TCP; 伝送制御プロトコル)の場合は正しい確立、その他のプロトコルの場合は双方向)と異常接続レート(TCP の場合は不正な確立、その他のプロトコルの場合は単一方向)を監視すること、および次の基準のうちいずれかに基づく異常検出条件をトリガーすることです。
• 合計接続レートが定義済みしきい値を超える。
• 不審接続レートが定義済みしきい値を超え、 かつ 不審接続と非不審接続の比率が定義済みしきい値を超える。
比率メトリックは特に強力な悪質アクティビティ インジケータであり、信頼できる悪質アクティビティ識別子としてレート修飾子とともに動作します。
異常検出は、検出された異常条件の方向に基づいて、次の 3 つのカテゴリに分類されます。3 つのカテゴリで使用されるコンセプトは同じですが、検出される悪質アクティビティの性質はカテゴリごとに異なります。
• スキャンおよびスウィープ ディテクタ:IP アドレス からの 接続レートにおける異常に基づく悪質アクティビティを検出します。
• Denial of Service(DoS; サービス拒絶)ディテクタ:一方が他方を攻撃している IP アドレスのペア間における接続レートの異常を検出します。単一の攻撃またはスケールが大きい DDoS 攻撃の一部である可能性があります。
• DDoS ディテクタ:IP アドレス に 着信する接続レートで異常(その IP アドレスが攻撃されている)を検出します。攻撃は、単一 IP アドレス(DoS)または複数の IP アドレスによって行われる可能性があります。
すべての種類の異常検出条件において、次のそれぞれにしきい値および実行されるトリガー処理を定義できるので、柔軟性が最大になります。
• フロー方向
• フロー プロトコル
• (オプション)TCP および User Datagram Protocol(UDP; ユーザ データグラム プロトコル)のポートの一意性
(注) ここで説明する GUI 設定は、前リリースで使用できた、SCE プラットフォームの攻撃フィルタリング モジュールを設定する Command-Line Interface(CLI; コマンドライン インターフェイス)コマンドの代わりとなります。
異常検出パラメータ
スキャンおよびスウィープ、DoS、DDoS という異常ディテクタ カテゴリごとに、1 つのデフォルト ディテクタがあります。カテゴリごとに別のディテクタを追加できます。各カテゴリのディテクタは順番に確認されます。ディテクタのしきい値設定に従った最初の一致によって検出がトリガーされます。ディテクタが確認される順序を設定できますが、デフォルト ディテクタは最後に確認されます。
異常ディテクタには、悪質トラフィックに関連する、最大 12 の異常タイプを含めることができます。
• ネットワーク主導:ネットワーク側から開始される悪質トラフィック
– TCP:すべてのポートの集約 TCP トラフィック
– TCP 特定ポート:すべての単一ポートの TCP トラフィック
– UDP:すべてのポートの集約 UDP トラフィック
– UDP 特定ポート:すべての単一ポートの UDP トラフィック
– ICMP:すべてのポートの集約 ICMP トラフィック
– その他:すべてのポートでその他のプロトコル タイプを使用した集約トラフィック
• サブスクライバ主導:サブスクライバ側から開始される悪質トラフィック
– TCP
– TCP 特定ポート
– UDP
– UDP 特定ポート
– ICMP
– その他
(注) DoS 攻撃ディテクタでは、ICMP およびその他の異常タイプを使用できません。
ディテクタの各異常タイプには次の属性が関連します。
• 検出しきい値:2 つのしきい値があり、どちらかを超えるということは、攻撃が進行中であると定義されることになります。
– セッション レートしきい値:異常検出条件をトリガーする、単一 IP アドレスの指定ポートにおける 1 秒間のセッション数。
– 不審セッションしきい値:不審セッションとは、適切に確立されていないセッション(TCP の場合)、または単一方向セッション(その他のプロトコルの場合)のことです。不審セッション レート および 不審セッション比率の両方を超えると、異常検出条件がトリガーされます。セッション レートが比較的高くて応答レートが低い場合は、一般的に悪質アクティビティを示します。
不審セッション レート:単一 IP アドレスの指定ポートにおける、1 秒間の不審セッション数。
不審セッション比率:不審セッション レートと合計セッション レートの比率(パーセンテージ)。比率が高い場合は多くのセッションが応答を受けないことを意味し、悪質アクティビティを示します。
• 処理:異常検出条件がトリガーされたとき、次の処理のうち 0 個以上を実行できます(デフォルトでは処理が有効になっていません)。
(注) デバイス上のログ ファイルに異常をログすること、および Raw Data Report(RDR; 未加工データ レコード)の生成を異常タイプごとに設定することはできません。
– ユーザ警告:SNMP トラップを生成し(シスコ独自の MIB については、『 Cisco Service Control Application for Broadband Reference Guide 』の「SCA BB Proprietary MIB Reference」の章を参照してください)、異常の始まりと終わりを示します。
– サブスクライバ通知:ブラウジング セッションをキャプティブ ポータルにリダイレクトし、悪質アクティビティについて関連サブスクライバに通知します。ネットワーク攻撃に関するサブスクライバ通知を設定するには、「サブスクライバ通知の管理」を参照してください。
– 攻撃ブロック:関連セッションをブロックします。ブロックは、異常検出条件をトリガーした悪質トラフィックの仕様に基づいて実行されます。サブスクライバ通知を異常タイプで有効にしている場合、ブロックはブラウジングの関連ポート(デフォルトの場合は TCP ポート 80。「詳細サービス コンフィギュレーション オプションの管理」を参照)に適用されません。
ユーザ定義ディテクタにも、次の属性のうち 1 つ以上を含めることができます。
• IP アドレス リスト:リストされている IP アドレス範囲に検出を制限します。IP スウィープおよびポート スキャンの検出時に、送信元 IP に適用されます。DoS 攻撃および DDoS 攻撃の検出時には送信先 IP に適用されます。
• TCP ポート リスト:リストされている送信先 TCP ポートに検出を制限します。このリストは、TCP 指定ポート異常タイプだけに適用されます。
• UDP ポート リスト:リストされている送信先 UDP ポートに検出を制限します。このリストは、UDP 指定ポート異常タイプだけに適用されます。
異常検出設定の表示
すべての異常検出のリストを表示できます。異常ディテクタはツリー構造で表示され、ディテクタ カテゴリ(スキャンおよびスウィープ、DoS、DDoS)に従ってグループ化されます。
異常ディテクタごとに関連パラメータを表示し、ディテクタに組み込まれるすべての異常タイプのリスト、およびそのパラメータを表示できます。
ステップ 1 サービス セキュリティ ダッシュボードの [Anomaly Based Detection of Malicious Traffic] ペインで [Configure] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが表示されます。
ディテクタ ツリーがダイアログボックスの左側領域に表示され、右側領域は空になります(図 10-2)。
図 10-2 ディテクタ ツリー
ステップ 2 ディテクタ ツリーでディテクタを選択します。
ディテクタのパラメータがダイアログボックスの右上の領域に表示されます(図 10-3)。
図 10-3 ディテクタのパラメータ
ディテクタの定義済み異常タイプは、各パラメータの値とともにダイアログボックスの右下の領域にリスト表示されます。次の図は、スキャンおよびスウィープのデフォルト ディテクタのデフォルト パラメータ値を示しています(図 10-4)。
図 10-4 ディテクタの定義済み異常タイプ
単方向分類が有効になっている場合、不審セッション レートとセッション レートは同じに設定されます。この設定では、不審セッションによりトリガーされる異常検出が実質的に無効になります(図 10-5)。
図 10-5 セッション レートと不審セッション レートの比較
ステップ 3 [OK] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが閉じます。
異常ディテクタの追加
新しい異常ディテクタを追加できます。サービス コンフィギュレーションには 100 までの異常ディテクタを含めることができます。
新しいディテクタには、IP アドレス範囲、TCP ポートと UDP ポート、1 つの異常タイプを定義します。
ディテクタを定義したら、別の異常タイプを追加できます(「異常ディテクタの編集」を参照)。
ステップ 1 サービス セキュリティ ダッシュボードの [Anomaly Based Detection of Malicious Traffic] ペインで [Configure] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが表示されます。
ステップ 2 ディテクタ ツリーでディテクタ カテゴリを選択します。
ステップ 3 をクリックします。
Anomaly Detector Creation ウィザードが表示され(図 10-6)、[Malicious Traffic Detector] ページが開きます。
図 10-6 Anomaly Detector Creation ウィザード:[Malicious Traffic Detector]
ステップ 4 ディテクタのわかりやすい名前を [Name] フィールドに入力します。
ステップ 5 1 つ以上のチェック ボックスをオンにして、ディテクタのスコープを制限します。
関連フィールドが有効になります。
ステップ 6 IP アドレスやポートのリストを関連フィールドに入力します。
ステップ 7 [Next] をクリックします。
Anomaly Detector Creation ウィザードの [Malicious Traffic Characteristics for a WORM attack] ページが開きます(図 10-7)。
図 10-7 [Malicious Traffic Characteristics for a Worm Attack]
ステップ 8 定義しているディテクタ タイプに応じて、発信側またはターゲット側を選択します。
• スキャンおよびスウィープ ディテクタまたは DoS ディテクタを定義している場合は、定義している異常タイプの発信側を選択します。
• DDoS ディテクタを定義している場合は、定義している異常タイプのターゲット側を選択します。
ステップ 9 定義している異常タイプのトランスポート タイプを選択します。
ステップ 10 [Next] をクリックします。
Anomaly Detector Creation ウィザードの [Anomaly Detection Thresholds] ページが開きます(図 10-8)。
図 10-8 [Anomaly Detection Thresholds]
ステップ 11 この異常タイプのディテクタ設定を行います。
次のうちいずれかを実行します。
• デフォルト ディテクタの設定を使用するには、[Use the Default Detector's settings] チェックボックスをオンにします。
• [Flow Open Rate] フィールド、[Suspected Flows Rate] フィールド、[Ratio of Suspected Flow Rate] フィールドに値を入力します。
ステップ 12 [Next] をクリックします。
Anomaly Detector Creation ウィザードの [Anomaly Detection Action Settings] ページが開きます(図 10-9)。
図 10-9 [Anomaly Detection Action Settings]
ステップ 13 [Block]、[Alert]、[Notify Subscriber] の各処理を選択します。
ステップ 14 [Finish] をクリックします。
Anomaly Detector Creation ウィザードが閉じます。
新しいディテクタがディテクタ ツリーに追加されます。
異常ディテクタの編集
ユーザ定義異常ディテクタでは、次の処理を実行できます。
• ディテクタ パラメータの編集
• 異常タイプの編集
• 異常タイプの追加
• 異常タイプの削除
• ディテクタ ツリーにおけるディテクタの順序の変更
ディテクタ カテゴリごとに、ディテクタはディテクタ ツリーにリストされている順序で 下から上に 確認され、デフォルト ディテクタは最後に確認されます。
3 つのデフォルト ディテクタでは異常タイプを編集できます。
ディテクタ パラメータの編集
ステップ 1 サービス セキュリティ ダッシュボードの [Anomaly Based Detection of Malicious Traffic] ペインで [Configure] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが表示されます。
ステップ 2 ディテクタ ツリーでディテクタを選択します。
ディテクタのパラメータがダイアログボックスの右上の領域に表示されます。
ステップ 3 ディテクタの新しい名前を [Name] フィールドに入力します。
ステップ 4 IP アドレス範囲およびポートのチェックボックスのオンまたはオフを行います。
ステップ 5 IP アドレスやポートのリストの入力または修正を関連フィールドで行います。
ステップ 6 [OK] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが閉じます。
変更が保存されます。
異常タイプの編集
ステップ 1 サービス セキュリティ ダッシュボードの [Anomaly Based Detection of Malicious Traffic] ペインで [Configure] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが表示されます。
ステップ 2 ディテクタ ツリーでディテクタを選択します。
異常タイプに関する情報がダイアログボックスの右下に表示されます。
ステップ 3 異常タイプをダブルクリックします。
Anomaly Detector Creation ウィザードが表示され、[Anomaly Detection Thresholds] ページが開きます(「異常タイプの追加」を参照)。
ステップ 4 この異常タイプのディテクタ設定を行います。
次のうちいずれかを実行します。
• デフォルト ディテクタの設定を使用するには、[Use the Default Detector's settings] チェックボックスをオンにします。
• [Flow Open Rate] フィールド、[Suspected Flows Rate] フィールド、[Ratio of Suspected Flow Rate] フィールドの値を変更します。
ステップ 5 [Next] をクリックします。
Anomaly Detector Creation ウィザードの [Anomaly Detection Action Settings] ページが開きます。
ステップ 6 [Block]、[Alert]、[Notify Subscriber] の各処理を変更します。
ステップ 7 [Finish] をクリックします。
Anomaly Detector Creation ウィザードが閉じます。
異常タイプが変更した内容で更新されます。
ステップ 8 ステップ 3 ~ 7、またはステップ 2 ~ 7 をその他の異常タイプで繰り返します。
ステップ 9 [OK] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが閉じます。
異常タイプの追加
ステップ 1 サービス セキュリティ ダッシュボードの [Anomaly Based Detection of Malicious Traffic] ペインで [Configure] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが表示されます。
ステップ 2 ディテクタ ツリーでディテクタを選択します。
異常タイプがダイアログボックスの右下の領域にリスト表示されます。
ステップ 3 ([Create New Detector Item Under Detector Items Feature])をクリックします。
Anomaly Detector Creation ウィザードが表示され、[Malicious Traffic Characteristics for a WORM attack] ページが開きます(「異常ディテクタの追加」を参照)。
ステップ 4 定義している異常タイプの発信元を選択します。
ステップ 5 定義している異常タイプのトランスポート タイプを選択します。
ステップ 6 [Next] をクリックします。
Anomaly Detector Creation ウィザードの [Anomaly Detection Thresholds] ページが開きます。
ステップ 7 この異常タイプのディテクタ設定を行います。
次のうちいずれかを実行します。
• デフォルト ディテクタの設定を使用するには、[Use the Default Detector's settings] チェックボックスをオンにします。
• [Flow Open Rate] フィールド、[Suspected Flows Rate] フィールド、[Ratio of Suspected Flow Rate] フィールドに値を入力します。
ステップ 8 [Next] をクリックします。
Anomaly Detector Creation ウィザードの [Anomaly Detection Action Settings] ページが開きます。
ステップ 9 [Block]、[Alert]、[Notify Subscriber] の各処理を選択します。
ステップ 10 [Finish] をクリックします。
Anomaly Detector Creation ウィザードが閉じます。
新しい異常タイプが異常タイプ リストに追加されます。
ステップ 11 ステップ 3 ~ 10、またはステップ 2 ~ 10 をその他の異常タイプで繰り返します。
ステップ 12 [OK] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが閉じます。
異常タイプの削除
ステップ 1 サービス セキュリティ ダッシュボードの [Anomaly Based Detection of Malicious Traffic] ペインで [Configure] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが表示されます。
ステップ 2 ディテクタ ツリーでディテクタを選択します。
異常タイプがダイアログボックスの右下の領域にリスト表示されます。
ステップ 3 異常タイプ リストで異常タイプを選択します。
ステップ 4 をクリックします。
選択した異常タイプが異常タイプ リストから削除されます。
ステップ 5 ステップ 3 ~ 4、またはステップ 2 ~ 4 をその他の異常タイプで繰り返します。
ステップ 6 [OK] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが閉じます。
ディテクタが確認される順序の変更
ステップ 1 サービス セキュリティ ダッシュボードの [Anomaly Based Detection of Malicious Traffic] ペインで [Configure] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが表示されます。
ステップ 2 ディテクタ ツリーでディテクタを選択します。
ツリーにおけるディテクタの位置により、上矢印か下矢印、またはその両方が有効になります(図 10-10)。
図 10-10 ディテクタ ツリー
ステップ 3 このナビゲーション矢印を使用し、目的の位置にディテクタを移動します。
ステップ 4 ステップ 2 ~ 3 をその他のディテクタに繰り返します。
ステップ 5 [OK] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが閉じます。
変更が保存されます。
異常ディテクタの削除
任意のユーザ定義ディテクタまたはすべてのユーザ定義ディテクタを削除できます。
3 つのデフォルト ディテクタは削除できません。
ステップ 1 サービス セキュリティ ダッシュボードの [Anomaly Based Detection of Malicious Traffic] ペインで [Configure] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが表示されます。
ステップ 2 ディテクタ ツリーで 1 つ以上のユーザ定義ディテクタを選択します。
ステップ 3 をクリックします。
[Confirm Delete] メッセージが表示されます(図 10-11)。
図 10-11 [Confirm Delete]
ステップ 4 [OK] をクリックします。
選択したディテクタが削除され、ディテクタ ツリーに表示されなくなります。
ステップ 5 [OK] をクリックします。
[Anomaly Detection Settings] ダイアログボックスが閉じます。
スパム検出の管理
異常 E メール検出方式は、単一サブスクライバの SMTP セッション レートを監視します。単一サブスクライバからの SMTP セッション レートが高いということは、E メール送信に関連する悪質アクティビティを一般的に示します(E メールベースのウイルスまたはスパムゾンビ アクティビティ)。
この方式は、システムがサブスクライバアウェア モードまたはアノニマス サブスクライバ モードに設定されている場合に限り機能します。これにより SCE は、サブスクライバごとに開始される SMTP セッション数を正確にカウントできます。
この検出方式は、次の考え方に基づいています。
• 一般的なダッシュボード サブスクライバは、少数のセッションを開始します(最大でも、E メール メッセージを送信するたびに 1 つのセッション)。
• 一般的なダッシュボード サブスクライバは、通常、(メール クライアントで設定されているように)Internet Service Provider(ISP; インターネット サービス プロバイダー)の SMTP サーバをメール リレーのためだけに使用します。オフネットの SMTP サーバと通信することはありません。
• スパム ゾンビは、主にオフネット サーバ(メッセージの指定された受信者のメール サーバ)向けに多数の SMTP セッションを作成します。
スパム検出を設定する場合は、適切な監視対象サービスを選択します。デフォルトでは、組み込み SMTP サービスです。検出感度を向上させるために、さらに具体的なサービスを作成して検出のスコープを狭めることができます。次の 2 つのサービスを設定できます。
• 「発信 SMTP」:サブスクライバによって開始される SMTP セッション。
• 「オフネット SMTP」:サブスクライバの ISP の SMTP サーバをターゲットと しない SMTP セッション。サービスをオフネットに限定すると、正規セッションをカウントしないようにできます。
(注) 著名な非 ISP E メール プロバイダー(たとえば、Google および Yahoo!)は SMTP ベースのサービスを提供しているので、オフネットは、正規アクティビティと非正規アクティビティを良好に区別するとは言えなくなっています。オフネット サービスを改善するには、「オンネットの SMTP」サービス定義に SMTP サーバ リストを含める必要があります。これによって、他のすべての SMTP サーバがオフネットになります。
スパム検出の設定
ステップ 1 サービス セキュリティ ダッシュボードの [Spam Zombies and Email Viruses Detection] ペインの [Configure] をクリックします。
[Spam Detection and Mitigation Settings] ダイアログボックスが表示されます(図 10-12)。
図 10-12 [Spam Detection and Mitigation Settings]
ステップ 2 (オプション)スパム検出を無効にするには、[Enable Spam detection and mitigation] チェックボックスをオフにします。その他すべてのフィールドも無効になります。
ステップ 7 に進んでください。
ステップ 3 [Service to monitor for Spam] ドロップダウン リストから監視対象サービスを選択します。
(注) 「発信 SMTP」や「オフネット SMTP」などのさらに具体的なサービスを定義している場合を除いて、監視対象サービス(SMTP)のデフォルト値を変更しないでください。
ステップ 4 各パッケージについて次の処理を実行します。
a. 異常な E メール アクティビティを示すために使用するクォータを定義します。クォータは、一定期間のセッション数として定義されます(セッション数と期間のいずれも設定可能)。これらのフィールドの値は、サブスクライバ アクティビティのベースライン監視に基づいて設定することが推奨されます。
– [Detection threshold] カラムをクリックします。
[More] ボタン()が表示されます。
– [More] ボタンをクリックします。
– 異常動作の E メール セッション レートのしきい値を定義します(図 10-13)。
– [OK] をクリックします。
図 10-13 [Spam Detection Threshold]
b. 大量メール送信アクティビティを検出した場合のアクションを 1 つ以上定義します。
次のアクションから選択できます。
– [Send RDR]:1 つの RDR が SCE から Collection Manager(CM)に送信され、スパム送信者としてのサブスクライバのステータスが削除されると、第 2 の RDR が送信されます。CM は、ロギング目的でこれらの RDR を CSV ファイルに収集します。または、独自の RDR コレクタを実装して、これらの RDR を受信し、リアルタイムで応答できます。
– [Block selected service Traffic]:スパム SMTP トラフィックをブロックします。
– [Notify Subscriber (HTTP)]:サブスクライバのブラウジング セッションをキャプティブ ポータルにリダイレクトし、オペレータからのメッセージを示します。これは、「サブスクライバ通知」を使用して行います。
– [Mirror SMTP traffic]:スパム SMTP トラフィックをインライン スパム検出サービスに迂回させます。
(注) [Send RDR] アクションでは、サブスクライバがスパム送信者として示されると 1 つの RDR が送信され、サブスクライバがスパム送信者と見なされなくなると第 2 の RDR が送信されます。しかし、ブロック、通知、およびミラーリングの各処理を使用する場合、サブスクライバがスパム送信者として示されると処理が開始され、サブスクライバがスパム送信者と見なされなくなるまで続行されます。
(注) [Block selected service Traffic] および [Mirror SMTP traffic] の両方を選択することはできません。
ステップ 5 [Notify Subscriber (HTTP)] を選択した場合、サブスクライバへの通知を選択するか、入力します。
ステップ 6 [Mirror SMTP traffic] を選択した場合、サーバ グループを選択します。
ステップ 7 [Finish] をクリックします。
[Spam Detection and Mitigation settings] ダイアログボックスが閉じます。
悪質トラフィックに関するレポート
Reporter ツールでは、悪質トラフィックに関する多くのレポートを表示できます。
• グローバル レポート
– Global Scan/Attack Rate
– Global DoS Rate
– Infected Subscribers
– Infected Subscribers versus Active Subscribers
– DoS Attacked Subscribers
– Top Scanned/Attacked ports
• 個別サブスクライバまたはホストのレポート
– Top Scanning/Attacking hosts
– Top DoS Attacked hosts
– Top DoS Attacked Subscribers
– Top Scanning/Attacking Subscribers
サービス セキュリティ レポートの表示
ステップ 1 サービス セキュリティ ダッシュボードの関連ペインで [View Report] をクリックします。
[Choose a report] ダイアログボックスが表示され、関連レポートのツリーが表示されます。
ステップ 2 レポートのツリーからレポートを選択します。
ステップ 3 [OK] をクリックします。
[Choose a report] ダイアログボックスが閉じます。
Reporter ツールが Console で開き、要求したレポートが表示されます。
ステップ 4 レポートの操作方法および保存方法については、『 Cisco Service Control Application Reporter User Guide 』の「Working with Reports」の章を参照してください。
トラフィック フローのフィルタリング
フィルタ規則はサービス コンフィギュレーションの一部です。フィルタ規則は、フローのレイヤ 3 プロパティおよびレイヤ 4 プロパティに基づいて、次のように Service Control Engine(SCE)プラットフォームに指示できます。
• [Bypass]:フローを無視し、変更無しで伝送します。
• [Quick forward]:フローを複製し、複製の一方を送信キューに送信して遅延を最小限にとどめます。もう一方の複製は、通常のパケット パスで送信されます。
トラフィック フローが SCE プラットフォームに着信すると、SCE プラットフォームはこのフローにフィルタ規則を適用するかどうかを確認します。
このトラフィック フローにフィルタ規則を適用する場合、SCE プラットフォームはトラフィック フローを送信キューに渡します。RDR の生成またはサービス コンフィギュレーションの実施は行われません。このフローは、分析用に生成されるレコードに現れず、アクティブなサービス コンフィギュレーションに属す規則によって制御されません。
SCE プラットフォームを通過する Operational Support System(OSS; オペレーション サポート システム)プロトコル(Dynamic Host Configuration Protocol(DHCP; ダイナミック ホスト コンフィギュレーション プロトコル)など)、およびルーティング プロトコル(Border Gateway Protocol(BGP; ボーダー ゲートウェイ プロトコル)など)にフィルタ規則を追加することを推奨します。このようなプロトコルは一般的にポリシーの実施から影響を受けず、ボリュームが少ないので、レポートする必要性はあまりありません。
すべての新しいサービス コンフィギュレーションには、多くの定義済みフィルタ規則が組み込まれます。
(注) デフォルトの場合は、すべてではなく、一部の定義済みフィルタ規則がアクティブになっています。
特定プロトコルのフローを、そのフローのレイヤ 7 特性に基づいてフィルタリングすることもできます(「詳細サービス コンフィギュレーション オプションの管理」を参照)。他のフィルタ処理されたフローの場合と同様に、レイヤ 7 によってフィルタ処理されたフローは制御されませんが、分類およびレポートは可能です。フィルタ処理可能なプロトコルのフローは一般的に短く、全体のボリュームは無視できます。したがって、これらのプロトコルをフィルタリングしてもネットワーク帯域幅と SCA BB レポートの精度にほとんど影響を与えません。
• 「トラフィック フィルタリングについての情報」
• 「パッケージのフィルタ規則の表示」
• 「フィルタ規則の追加」
• 「フィルタ規則の編集」
• 「フィルタ規則の削除」
• 「フィルタ規則の無効化と有効化」
SCA BB Filtered Traffic メカニズム
SCA BB Filtered Traffic メカニズムは、関連フローに一致する フィルタ規則 を定義し、これらのフローに正しいアクションを割り当てることによって遅延を低減したり、あるいはトラフィックの一部を完全に迂回させます。パケットのレイヤ 3 およびレイヤ 4 のプロパティに従って、フィルタ規則がパケットに一致します。これらのプロパティとは、IP アドレス、ポート番号、Differentiated Service Code Point(DSCP; Diffserv コード ポイント)Type of Service(ToS)、およびパケットの送信元である SCE プラットフォーム インターフェイス(サブスクライバまたはネットワーク)などです。フィルタ規則と一致するパケットについては、次の処理を適用できます。
• 現在のパケットを迂回する(遅延を低減し、トラフィック制御を回避するため)。
この処理が適用されると、現在のパケットは、サービス コンフィギュレーションによる処理またはレポートを経ずに、SCE プラットフォームから直接送信されます。迂回されたパケットは、Class of Service(CoS; サービス クラス)にマップして、SCE プラットフォームの送信キューの 1 つに割り当てる必要があります。
指定可能な CoS の値は、BE、AF1、AF2、AF3、AF4、および EF です。EF は、処理優先度が高いことを示し、他のクラスは通常の処理優先度であることを示します。
• フローのクイック フォワード(遅延低減のため)。
この処理が適用されると、現在のパケットおよび同じフローに属する以降のすべてのパケットが複製され、2 つの異なるパスで送信されます。元のパケットは送信キューに直接送信されるので、最小限の遅延だけにとどまります。複製のパケットは、分類およびレポートのために通常のサービス コンフィギュレーション処理パスに送られてから破棄されます。
• フローを高処理優先度の入力キューに割り当てる(遅延低減のため)。
(注) このオプションは、すべてのプラットフォームでサポートされているわけではありません。
• この処理が適用されると、現在のパケットおよび同じフローに属する以降のすべてのパケットが高処理優先度の入力キューに入ります。これらのパケットは、同時に到着する他のパケットよりも先に、通常のサービス コンフィギュレーション処理パスを通過します。フローは、EF CoS にマップして SCE プラットフォームの高処理優先度の送信キューに割り当てる必要があります。
(注) Multiprotocol Label Switching(MPLS; マルチプロトコル ラベル スイッチング)環境では、SCE プラットフォームは DSCP ビットを MPLS ヘッダーの EXP ビットにマッピングしません。
フィルタ規則は、上記のいずれかの処理と同時に、(パケットの DSCP ToS フィールドを変更することによって)一致したトラフィックの DSCP ToS マーキングを実行できます。
(注) DSCP ToS マーキングおよび CoS への割り当ては、システムの動作モードが Full Functionality の場合に限り実行できます(「システムの動作モード」を参照)。
フィルタ規則の処理
迂回処理およびクイック フォワード処理は、さまざまなスコープのトラフィックに適用されます。
• 迂回処理は、現在のパケットを迂回させるだけです。同じフローの以降のすべてのパケットは、Filtered Traffic メカニズムを通過します。つまり、たとえばトラフィックが宛先ポート番号に基づいて迂回される場合、双方向フローの両側からのパケットを一致させるためには 2 つの規則を作成する必要があります。
たとえば、宛先ポート 23 に向かうすべてのトラフィックを迂回させるには、ネットワーク側のポート 23 を宛先とするサブスクライバ側から到着するパケット用に 1 つと、サブスクライバ側のポート 23 を宛先とするネットワークから到着するパケット用に 1 つの 2 つの規則が必要です。
• クイック フォワード処理は、フロー全体に適用されます。1 回識別されると、以降のすべてのパケットはフィルタ規則メカニズムではなく、通常のサービス コンフィギュレーション処理の対象となります。
パケットは、複数のフィルタ規則に一致する場合があります。迂回とクイック フォワードの両方に一致した場合、パケット/フローは最小限の遅延で迂回されます。さらに、迂回だけに一致した場合も、パケット/フローは最小限の遅延で迂回されます。
フィルタ規則とサービス規則
遅延を低減させるフィルタ規則の処理により、SCE プラットフォームがフローを制御できるようになります。つまり、サービス規則に一致する場合、フローをブロックしたり、限定された帯域幅を設定したりできます。たとえば、フィルタ規則が適用されて遅延が低減され、一方で同じトラフィックにサービス コンフィギュレーション規則が適用されてブロックされる場合、トラフィックはブロックされます。
迂回処理は、サービス コンフィギュレーション処理を回避するように設計されています。迂回されたトラフィックは、サービス規則の影響を受けません。
メディア フローの自動クイック フォワーディング
SCE プラットフォームは、分類時に SIP、MGCP、H323、Skinny、および Real-Time Streaming Protocol(RTSP)メディア フローに対してクイック フォワーディング処理を適用することによって、遅延に影響されやすい音声およびビデオのメディア フローの遅延を低減します。つまり、メディア フローがこれらのタイプの 1 つとして分類されると、ただちにクイック フォワーディングの対象となります。SCE プラットフォームは、フィルタ規則のコンフィギュレーションに関わらず、自動的にクイック フォワーディングを行います。これらのメディア フローがサービス規則に一致する場合には、ブロックされたり、限定的な帯域幅が提供されることがあります。
パッケージのフィルタ規則の表示
サービス コンフィギュレーションに組み込まれているフィルタ規則のリストを表示できます。
フィルタ規則ごとのリストには、規則の名前、ステータス、簡潔な説明(システムが生成)が含まれます。
フィルタ規則の詳細情報を表示するには、[Edit Filter Rule] ダイアログボックスを開きます(「フィルタ規則の編集」を参照)。
ステップ 1 [Policies] タブで [Filtered Traffic] ノードを選択します。
すべてのフィルタ規則のリストが右の規則ペインに表示されます(図 10-14)。
図 10-14 フィルタ規則
フィルタ規則の追加
Add Filter Rule ウィザードは、フィルタ規則の追加プロセスを示します。
ステップ 1 [Policies] タブで [Filtered Traffic] ノードを選択します。
ステップ 2 右の規則ペインで、 ([Add Rules])をクリックします。
Add Filter Rule ウィザードが表示されます(図 10-15)。
図 10-15 Add Filter Rule
ステップ 3 [Next] をクリックします。
Add Filter Rule ウィザードの [Transport Type and Direction] ページが開きます(図 10-16)。
図 10-16 [Transport Type and Direction]
ステップ 4 トランスポート タイプおよび開始側を選択し、[Next] をクリックします。
Add Filter Rule ウィザードの [Subscriber-Side IP Address] ページが開きます(図 10-17)。
図 10-17 [Subscriber-Side IP Address]
ステップ 5 サブスクライバ側の IP アドレスを定義し、[Next] をクリックします。
Add Filter Rule ウィザードの [Network-Side IP Address] ページが開きます(図 10-18)。
図 10-18 [Network-Side IP Address]
ステップ 6 ネットワーク側の IP アドレスを定義し、[Next] をクリックします。
ステップ 4 で選択したトランスポート タイプが TCP または UDP ではない 場合は、Add Filter Rule ウィザードの [ToS] ページが開きます。ステップ 9 に進んでください。
ステップ 4 で選択したトランスポート タイプが TCP か UDP の場合は、Add Filter Rule ウィザードの [Subscriber-Side Port] ページが開きます(図 10-19)。
図 10-19 [Add Filter Rule]
ステップ 7 サブスクライバ側のポートを定義し、[Next] をクリックします。
Add Filter Rule ウィザードの [Network-Side Port] ページが開きます(図 10-20)。
図 10-20 [Network-Side Port]
ステップ 8 ネットワーク側のポートを定義し、[Next] をクリックします。
Add Filter Rule ウィザードの [ToS] ページが開きます(図 10-21)。
図 10-21 [ToS]
ステップ 9 ToS を定義し、[Next] をクリックします。
(注) ToS に指定できる値は 0 ~ 63 です。
Add Filter Rule ウィザードの [Action and Class-of-Service] ページが開きます(図 10-22)。
図 10-22 [Action and Class-of-Service]
ステップ 10 必要な処理のオプション ボタンを選択します。
• [Bypass]:このフィルタ規則に一致するパケットは SCA BB に渡されません。
• [Quick Forward]:SCE プラットフォームでは、このフィルタ規則に一致するパケットの低遅延が保証されます(遅延に影響されやすいフローに使用)。パケットは複製され、SCA BB に渡されて処理されます。
ステップ 11 CoS の値を選択して [Next] をクリックします。
Add Filter Rule ウィザードの [ToS Marking] ページが開きます(図 10-23)。
図 10-23 [ToS Marking]
ステップ 12 (オプション)フィルタ処理されたトラフィックのパケットの DSCP ToS マーカーを変更するには、必要に応じて [Remark Upstream ToS with ToS Marker] チェックボックスおよび [Remark Downstream ToS with ToS Marker] チェックボックスをオンにし、ドロップダウン リストから必要な ToS マーカーを選択し、[Next] をクリックします。
• [ToS Marking Settings] ダイアログボックスで方向性の DSCP ToS マーキングを無効にした場合(「DSCP ToS マーカー値の管理」を参照)、フィルタによる方向の DSCP ToS マーキングよりも優先されます(つまり、DSCP ToS 値は変更されません)。この場合、[Problems] 画面に警告が表示されます。
• ステップ 4 で一方向のフローをフィルタ処理したものの、このステップで別の方向の ToS マーキングを選択した場合、フィルタ規則は作成されますが、DSCP ToS の再マーキングは行われません。この場合、[Problems] 画面に警告が表示されます。
• 前のステップで [Quick Forward] を選択した場合、SCA BB は 元の パッケージを受け取り、処理します。つまり、フィルタ規則で選択された ToS マーキング アクションに関係なく、元の DSCP ToS 値が認識されます。
Add Filter Rule ウィザードの [Finish] ページが開きます(図 10-24)。
図 10-24 [Finish]
ステップ 13 新しいフィルタ規則の一意の名前を [Rule Name] フィールドに入力します。
(注) フィルタ規則にはデフォルトの名前を使用できますが、わかりやすい名前の入力を推奨します。
ステップ 14 (オプション)フィルタ規則をアクティブにするには、[Activate this rule] チェックボックスをオンにします。トラフィックのフィルタリング基準となるのは、アクティブな規則だけです。
ステップ 15 [Finish] をクリックします。
Add Filter Rule ウィザードが閉じます。
フィルタ規則が追加され、[Filter Rule] テーブルに表示されます。
フィルタ規則の編集
フィルタ規則のパラメータを表示および編集できます。
ステップ 1 [Policies] タブで [Filtered Traffic] ノードを選択します。
すべてのフィルタ規則のリストが右の規則ペインに表示されます。
ステップ 2 [Filter Rule] テーブルで規則を選択します。
ステップ 3 ([Edit Rule])をクリックします。
Edit Filter Rule ウィザードの [Introduction] ページが表示されます。
Edit Filter Rule ウィザードは Add Filter Rule ウィザードと同じです。
ステップ 4 「フィルタ規則の追加」のステップ 4 ~ 14 の手順に従います。
ステップ 5 [Finish] をクリックします。
フィルタ規則が変更され、関連変更内容が [Filter Rule] テーブルに表示されます。
フィルタ規則の削除
フィルタ規則を削除できます。サブスクライバ IP アドレスごとに定義された各規則に従って、IP アドレスおよびその属性の処理を再開する場合などにフィルタ規則を削除すると便利です。
ステップ 1 [Policies] タブで [Filtered Traffic] ノードを選択します。
すべてのフィルタ規則のリストが右の規則ペインに表示されます。
ステップ 2 [Filter Rule] テーブルで規則を選択します。
ステップ 3 ([Delete Rule])をクリックします。
[Filter Rule Warning] メッセージが表示されます(図 10-25)。
図 10-25 [Filter Rule Warning]
ステップ 4 [Yes] をクリックします。
フィルタ規則が削除され、[Filter Rule] テーブルに表示されなくなります。
フィルタ規則の無効化と有効化
フィルタ規則の有効化または無効化はいつでも実行できます。フィルタ規則の無効化にはフィルタ規則の削除と同じ効果がありますが、パラメータはサービス コンフィギュレーションに保持され、あとでフィルタ規則を再び有効にすることができます。
ステップ 1 [Policies] タブで [Filtered Traffic] ノードを選択します。
すべてのフィルタ規則のリストが右の規則ペインに表示されます。
ステップ 2 [Filter Rule] テーブルで規則を選択します。
ステップ 3 規則を有効にするには、[Active] チェックボックスをオンにします。
ステップ 4 規則を無効にするには、[Active] チェックボックスをオフにします。
ステップ 5 ステップ 3 ~ 4 をその他の規則に繰り返します。
サブスクライバ通知の管理
サブスクライバ通知機能では、サブスクライバ HTTP トラフィックが関連 Web ページにリダイレクトされて、Web ベースのメッセージがサブスクライバに示されます。これらの Web ページには、クォータ枯渇の通知など、サブスクライバに関連する情報が含まれています。HTTP のリダイレクションは、サブスクライバ通知がアクティブになると開始し、サブスクライバ通知が解除されると終了します。
(注) 単方向分類が有効になっている場合、サブスクライバ通知はサポートされません。
サブスクライバ リダイレクション パラメータの各セットは、通知リダイレクト プロファイルを含んでいます。Cisco Service Control Application for Broadband(SCA BB)では、(通知プロファイルおよびリダイレクト プロファイルを含む)最大 128 のリダイレクト プロファイルがサポートされます。削除できないデフォルトのリダイレクト プロファイルには、デフォルト通知、ネットワーク攻撃通知、およびデフォルトのリダイレクションの 3 種類があります。規則を定義するときに使用する通知リダイレクト プロファイルを設定します。
• 「サブスクライバ通知パラメータ」
• 「ネットワーク攻撃通知」
• 「通知リダイレクト プロファイルの追加」
• 「リダイレクション URL セットの追加」
サブスクライバ通知パラメータ
各リダイレクト プロファイル タイプの通知には、次のサブスクライバ通知パラメータが含まれています。
(注) [Activation trigger configuration] オプションは、リダイレクト プロファイル タイプのリダイレクトにだけ使用できます。
• [Name]:各プロファイルの名前は、一意である必要があります。
(注) デフォルト通知またはネットワーク攻撃通知の名前を変更することはできません。
• [Redirect profile type]:各プロファイルは、次の 2 つのタイプのいずれかです。
– [Notification]
– [Redirect]
• [Set of Redirection URLs]:リダイレクションをアクティブにしたあとでサブスクライバの HTTP フローがリダイレクトされる、設定可能な宛先 URL。この Web ページには、通常、サブスクライバに伝達する必要があるメッセージが含まれています。このリダイレクション セットは、リダイレクト理由およびサブスクライバ ID を含む宛先 URL に追加される 1 つまたは複数のパラメータを含むことができます。
宛先 Web サーバではこのパラメータを使用し、意味のあるメッセージをサブスクライバに伝えることができます。
• [Activation frequency]:通知リダイレクトをアクティブにする時期を示します。このアクティベーション頻度は、次のいずれかです。
(注) [Periodically] オプションは、リダイレクト プロファイル タイプのリダイレクトの場合にだけ使用できます。
• [Only once]:サブスクライバは、条件が一致した初回だけ通知にリダイレクトされます。
たとえば、クォータを超過した場合、サブスクライバが宛先 URL をブラウズすると、サブスクライバに通知されます(サブスクライバが引き続き違反状態である場合も同様です)。
• [Always]:サブスクライバは、条件が一致するたびに通知にリダイレクトされます。
たとえば、クォータを超過した場合、サブスクライバが自身のクォータをリフレッシュする手順を完了するまで、何回もリダイレクトされます。
• [Until the subscriber browses to]:サブスクライバが宛先 URL から別の最終 URL に進むまで、条件が一致するたびに通知にリダイレクトされます。
たとえば、クォータを超過した場合、宛先 URL にある Web ページで、メッセージを参照したあとに [Acknowledge] ボタンを押すように、サブスクライバに要求することができます。確認応答 URL は解除 URL として定義され、以降の通知は非アクティブになります。
解除 URL は、URL ホスト名、URL パス、これらを区切るコロンで構成されます。フォーマットは次のとおりです。
– < hostname > の前にワイルドカード(*)を付加して、同じサフィックスを持つすべてのホスト名と一致させることができます。
– パス要素は、常に「/」で開始する必要があります。
– < path > のあとにワイルドカード(*)を付加して、共通のプレフィクスを持つすべてのパスと一致させることができます。
たとえば、*. some-isp.net:/redirect/ * というエントリは、次のすべての URL と一致します。
• www.some-isp.net/redirect/index.html
• support.some-isp.net/redirect/info/warning.asp
• noquota.some-isp.net/redirect/acknowledge.aspx?ie=UTF-8
• [List of Allowed URLs]:リダイレクションがアクティブでも、ブロックとリダイレクトが行われない URL のリスト。
リダイレクションをアクティブにしたあとで、宛先 URL および解除 URL へのフローを除くすべての HTTP フローはブロックされて、宛先 URL にリダイレクトされます。ただし、サブスクライバに追加 URL セットへのアクセスを許可することができます。たとえば、サブスクライバが詳細サポート情報にアクセスできるようにする場合は、これが便利です。
許可 URL の形式は解除 URL と同じです。
これらのパラメータは、新しい通知リダイレクト プロファイルを追加したときに定義されます(「リダイレクション URL セットの追加」を参照)。パラメータの修正はいつでもできます。
ネットワーク攻撃通知
サブスクライバ通知では、サブスクライバにマッピングされた IP アドレスに関連する現在の攻撃について、サブスクライバにリアルタイムで通知されます (これらの通知を有効にする方法は、「サービス セキュリティ ダッシュボード」を参照してください)。SCA BB は、サブスクライバから送信された HTTP フローを、攻撃に関する情報を提供するサーバへリダイレクトして、攻撃についてサブスクライバに通知します。
サブスクライバ通知の 1 つであるネットワーク攻撃通知はこの通知専用であり、削除できません。ネットワーク攻撃通知は攻撃の最後で解除されず、サブスクライバは応答する 必要があります 。
トラフィックのブロック時にリダイレクションを許可するには、1 つの指定 TCP ポート(デフォルトではポート 80)を開いておくようにシステムを設定します。「詳細サービス コンフィギュレーション オプションの管理」を参照してください。
注意 これまでのリリースの SCA BB では、CLI コマンドを使用してネットワーク攻撃通知を設定していました。CLI コマンドをこの目的に使用する必要はなくなりました。
• 「ネットワーク攻撃通知パラメータ」
• 「説明テールを含む URL の例」
ネットワーク攻撃通知パラメータ
ネットワーク攻撃が検出されると、サブスクライバの HTTP フローは設定可能な宛先 URL にリダイレクトされます。この Web ページでは、サブスクライバに伝達する必要がある警告が表示されます。
宛先 URL には、通知パラメータを含むクエリー部分を含めることもできます。宛先 Web サーバではこのパラメータを使用し、サブスクライバへの特定の警告を作成できます。
宛先 URL のクエリー部分の形式は次のとおりです。
?ip=<ip>&side=<side>&dir=<dir>&prot=<protocol>&no=<open-flows>&nd=<suspected-flows>&to=<open-flows-threshold>&td=<suspected-flows-threshold>&ac=<action>&nh=>handled-flows>
表 10-1 に、テール内の各フィールドの意味を示します。
表 10-1 テール フィールドの説明
|
|
|
[ip] |
検出された IP アドレス |
|
[side] |
-- |
• s:サブスクライバ • n:ネットワーク |
[dir] |
-- |
• s:ソース • d:宛先 |
[protocol] |
-- |
• TCP • UDP • ICMP • OTHER |
[open-flows] |
オープン フロー数 |
-- |
[suspected flows] |
攻撃を受けた疑いのあるフロー数 |
-- |
[open-flows-threshold] |
オープン フローのしきい値 |
-- |
[suspected-flows-threshold] |
攻撃を受けた疑いのあるフローのしきい値 |
-- |
[action] |
-- |
• R:レポート • B:ブロックおよびレポート |
[handled-flows] |
攻撃開始以降に処理されたフロー数 (攻撃中および攻撃の最後ではゼロ以外) |
-- |
説明テールを含む URL の例
http://www.some-isp.net/warning?ip=80.178.113.222&side=s&proto=TCP&no=34&nd=4&to=34&td=10&ac=B&nh=100
通知リダイレクト プロファイルの追加
(注) 通知リダイレクト プロファイルを作成しても、サブスクライバ通知機能はアクティブになりません。通知リダイレクト プロファイルを定義したら、特定のパッケージに対してアクティブにする必要があります
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [Subscriber Redirection] を選択します。
[Redirect Actions Settings] ダイアログボックスが表示されます(図 10-26)。
図 10-26 [Redirect Action Settings]:[General] タブ
ステップ 2 [Add] をクリックします。
デフォルトのリダイレクション URL セットを含む新しいリダイレクション プロファイルが、リダイレクション プロファイル リストに追加されます。
ステップ 3 新しい通知リダイレクト プロファイルの一意の名前を [Name] フィールドに入力します。
(注) 通知リダイレクト プロファイルにはデフォルトの名前を使用できますが、わかりやすい名前の入力を推奨します。
ステップ 4 [Select redirection profile type] フィールドで、[Notification] を選択します。
このステップを省略しないでください。省略した場合、通知リダイレクト プロファイルではなく、リダイレクト プロファイルが作成されます。
ステップ 5 URL セットを選択します。
ステップ 6 [Activation] タブを選択します。
[Activation] タブが表示されます(図 10-27)。
図 10-27 [Activation] タブ
ステップ 7 リダイレクションがトリガーされる頻度を設定します。次のいずれかの [Activation frequency] オプション ボタンを選択します。
• [Only once]
• [Always]
• [Until the subscriber browses to]
ステップ 8 [Until the subscriber browses to] オプション ボタンを選択する場合は、表示されるフィールドに解除 URL ホストサフィックスおよびパスプレフィクスを入力します。
ステップ 9 [Allowed URLs] タブをクリックします。
[Allowed URLs] タブが開きます(図 10-28)。
図 10-28 [Allows URLs] タブ
ステップ 10 (オプション)許可 URL を 1 行に 1 つずつ入力します。
ステップ 11 [OK] をクリックします。
[Redirect Actions Settings] ダイアログボックスが閉じます。
通知リダイレクト プロファイルがプロファイル リストに追加されます。
サブスクライバ リダイレクションの管理
パッケージの規則によって、選択したプロトコルへのアクセスが拒否されることがあります。パッケージのサブスクライバが、ブロックされているプロトコルにアクセスしようとすると(たとえば「ゴールド」サブスクライバだけが使用可能なサービスに「シルバー」サブスクライバがアクセスしようとすると)、トラフィック フローはサーバにリダイレクトされ、リダイレクションの理由についてその Web ページで説明されます。この Web ページにより、パッケージをアップグレードする機会をサブスクライバに提供できます。規則を定義するときに使用するリダイレクション プロファイルを設定します。
(注) 単方向分類が有効になっている場合、リダイレクションはサポートされません。
各リダイレクト プロファイルは、一連のリダイレクト パラメータで構成されています。Cisco Service Control Application for Broadband(SCA BB)では、(通知リダイレクト プロファイルおよびリダイレクト プロファイルを含む)最大 128 のリダイレクト プロファイルがサポートされます。
サブスクライバ リダイレクト パラメータ
各リダイレクト タイプのリダイレクト プロファイルには、次のパラメータが含まれています。
• [Name]:各プロファイルの名前は、一意である必要があります。
(注) デフォルトのリダイレクション プロファイルの名前は変更できません。
• [Redirect profile type]:各プロファイルは、次の 2 つのタイプのいずれかです。
– [Notification]
– [Redirect]
• [Set of Redirection URLs]:リダイレクションをアクティブにしたあとでサブスクライバの HTTP フローがリダイレクトされる、設定可能な宛先 URL。このリダイレクション セットは、リダイレクト理由またはサブスクライバ ID を含む宛先 URL に追加される 1 つまたは複数のパラメータを含むことができます。
• [Activation trigger]:リダイレクトをトリガーするアクション。このアクティベーション トリガーは、次のいずれかです。
– [Subscriber clicks]:サブスクライバのリンク クリックによってリダイレクトがアクティブになる場合
– [Browse to a new site]:ブラウジングによってリダイレクトがアクティブになる場合
– [Any]:リンクまたはブラウジングによってリダイレクトがアクティブになる場合
• [Activation frequency]:リダイレクトをアクティブにする時期を示します。このアクティベーション頻度は、次のいずれかです。
– [Only once]:サブスクライバは、条件が一致した初回だけリダイレクトされます。
– [Always]:サブスクライバは、条件が一致するたびにリダイレクトされます。
– [Triggering events]
– [KBytes]
– [Until the subscriber browses to]:サブスクライバが宛先 URL から別の最終 URL に進むまで、条件が一致するたびにリダイレクトされます。
解除 URL は、URL ホスト名、URL パス、これらを区切るコロンで構成されます。フォーマットは次のとおりです。
– < hostname > の前にワイルドカード(*)を付加して、同じサフィックスを持つすべてのホスト名と一致させることができます。
– パス要素は、常に「/」で開始する必要があります。
– < path > のあとにワイルドカード(*)を付加して、共通のプレフィクスを持つすべてのパスと一致させることができます。
たとえば、*. some-isp.net:/redirect/ * というエントリは、次のすべての URL と一致します。
• www.some-isp.net/redirect/index.html
• support.some-isp.net/redirect/info/warning.asp
• noquota.some-isp.net/redirect/acknowledge.aspx?ie=UTF-8
• [List of Allowed URLs]:リダイレクションがアクティブでも、ブロックとリダイレクトが行われない URL のリスト。
リダイレクションをアクティブにしたあとで、宛先 URL および解除 URL へのフローを除くすべての HTTP フローはブロックされて、宛先 URL にリダイレクトされます。ただし、サブスクライバに追加 URL セットへのアクセスを許可することができます。たとえば、サブスクライバが詳細サポート情報にアクセスできるようにする場合は、これが便利です。
許可 URL の形式は解除 URL と同じです。
これらのパラメータは、新しい通知リダイレクト プロファイルを追加したときに定義されます。パラメータの修正はいつでもできます。
リダイレクト プロファイルの追加
リダイレクト プロファイルには、一連のリダイレクション URL およびリダイレクトをトリガーするアクションまたはリダイレクトが発生する頻度などリダイレクト機能を使用する条件が含まれています。
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [Subscriber Redirection] を選択します。
[Redirect Actions Settings] ダイアログボックスが表示されます(図 10-29)。
図 10-29 [Redirect Actions Settings]:[General] タブ
ステップ 2 [Add] をクリックします。
デフォルトのリダイレクション URL セットを含む新しいリダイレト プロファイルが、リダイレクト プロファイル リストに追加されます。
ステップ 3 新しいリダイレクト プロファイルの一意の名前を [Name] フィールドに入力します。
(注) リダイレト プロファイルにはデフォルトの名前を使用できますが、わかりやすい名前の入力を推奨します。
ステップ 4 URL セットを選択します。
ステップ 5 [Activation] タブを選択します。
[Activation] タブが表示されます(図 10-30)。
図 10-30 [Activation] タブ
ステップ 6 リダイレクションをトリガーするアクティビティを設定します。次のいずれかの [Activation trigger] オプション ボタンを選択します。
• [Subscriber clicks]
• [Browse to a new site]
• [Any]
ステップ 7 リダイレクションがトリガーされる頻度を設定します。次のいずれかの [Activation frequency] オプション ボタンを選択します。
• [Only once]
• [Always]
• [Periodically]
• [Until the subscriber browses to]
ステップ 8 [Periodically] オプション ボタンを選択した場合、[Every] フィールドに数字とインクリメントを入力してリダイレクションの発生頻度を指定します。
ステップ 9 [Until the subscriber browses to] オプション ボタンを選択した場合、表示されるフィールドに解除 URL を入力します。
ステップ 10 [Allowed URLs] タブをクリックします。
[Allowed URLs] タブが開きます(図 10-31)。
図 10-31 [Allowed URLs] タブ
ステップ 11 (オプション)ブラウズしてもよい 1 つまたは複数の URL を入力します。これは、リダイレクト条件よりも優先されます。
ステップ 12 [OK] をクリックします。
[Redirect Actions Settings] ダイアログボックスが閉じます。
リダイレクション プロファイルがリダイレクション プロファイル リストに追加されます。
リダイレクション プロファイルの削除
デフォルト リダイレクション プロファイルは削除できません。
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [Subscriber Redirection] を選択します。
[Redirect Actions Settings] ダイアログボックスが表示されます。
ステップ 2 プロファイルの名前をクリックします。
ステップ 3 [Remove] をクリックします。
ステップ 4 [OK] をクリックします。
[Redirect Actions Settings] ダイアログボックスが閉じます。
リダイレクション設定が保存されます。
リダイレクション URL セットの追加
Console のリダイレクション機能では、次の 3 つのプロトコルだけがサポートされます。
• HTTP Browsing
• HTTP Streaming
• RTSP Streaming
リダイレクション セットには、これらの 3 つのプロトコルにそれぞれ対応したリダイレクション オプションが 1 つずつ含まれています。システムはデフォルトのリダイレクション セットを提供しますが、これは削除できません。最大で 127 のリダイレクション セットを追加できます。
各リダイレクション URL には、次のフォーマットの URL 指定名、サブスクライバ ID、およびサービス ID が含まれています。
<URL>?n=<subscriber-ID>&s=<service-ID>
URL には、1 つまたは複数のパラメータを追加することもできます。
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [Subscriber Redirection] を選択します。
[Redirect Actions Settings] ダイアログボックスが表示されます。
ステップ 2 [General] タブで、[Edit] をクリックします。
[Redirect Set Settings] ダイアログボックスが表示されます(図 10-32)。
図 10-32 [Redirect Set Settings]
ステップ 3 [Add] をクリックします。
デフォルトのリダイレクション URL を含む新しいリダイレクション セットが追加されます。
ステップ 4 新しいリダイレクション セットの一意の名前を [Redirection Set Name] フィールドに入力します。
(注) リダイレクション セットにはデフォルトの名前を使用できますが、わかりやすい名前の入力を推奨します。
ステップ 5 新しいリダイレクション セットの [Redirection destination URLs] セクションに新しい値を入力します。
ステップ 6 (オプション)応答コードを含めるには、[Response code] チェックボックスをオンにし、ドロップダウン リストから応答コードを選択します。リダイレクション パラメータのリストおよび説明については、 表 10-2 を参照してください。
ステップ 7 (オプション)Cookie を含めるには、[Cookie] チェックボックスをオンにし、値を入力します。リダイレクション パラメータのリストおよび説明については、 表 10-2 を参照してください。
ステップ 8 (オプション)宛先 URL に追加する任意のパラメータのチェックボックスをオンにします。リダイレクション パラメータのリストおよび説明については、 表 10-2 を参照してください。
[Free text to append] チェックボックスをオンにする場合、URL に追加するテキストをテキスト ボックスに入力します。リダイレクション パラメータのリストおよび説明については、 表 10-2 を参照してください。
(注) 宛先 URL には、「<」および「>」は表示されません。
パラメータを含む宛先 URL の最大長は、500 文字です。
[Cookie] パラメータおよび [Referer] パラメータを使用できるのは、HTTP トラフィックだけです。
表 10-2 リダイレクション パラメータ
|
|
[Reason] |
通知の場合:通知番号。 DDoS 攻撃の場合:DDoS 攻撃 ID。 リダイレクトの場合:無効です。 |
[Subscriber ID] |
SCE に表示されるサブスクライバの名前。 |
[Service ID] |
SCE によって分類されたサービスの ID。 |
[Distinct Number] |
リダイレクトされたフローの固有識別情報。<redirected flow number:cpu number> の形式です。 |
[Time Stamp] |
時間(秒単位)。Unix 形式です。 |
[Free text to append] |
フリー テキスト。 |
[Referer] |
元のフロー要求に表示される参照元。参照元パラメータが設定されていない場合、““ が表示されます。 |
[Original Cookie] |
元のフロー要求に表示される cookie ストリング。cookie パラメータが設定されていない場合、““ が表示されます。 |
[Original Host] |
元のフロー要求に表示されるホスト名。 |
[Original URL] |
元のフロー要求に表示される URL。 |
[Original Parameters] |
元のフロー要求に表示される URL パラメータ。URL パラメータが設定されていない場合、““ が表示されます。 |
ステップ 9 [OK] をクリックします。
設定が保存され、[Redirect Set Settings] ダイアログボックスが閉じます。
リダイレクション URL セットの削除
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [Subscriber Redirection] を選択します。
[Redirect Actions Settings] ダイアログボックスが表示されます。
ステップ 2 [General] タブで、[Edit] をクリックします。
[Redirect Set Settings] ダイアログボックスが表示されます。
ステップ 3 リダイレクション セットの名前をクリックします。
ステップ 4 [Remove] をクリックします。
ステップ 5 [OK] をクリックします。
[Redirect Set Settings] ダイアログボックスが閉じます。
リダイレクション設定が保存されます。
システム設定の管理
Console では、次を制御するさまざまなシステム パラメータを判別できます。
• システムの動作状態
• 非対称ルーティング分類モードのイネーブル化とディセーブル化
• 詳細サービス コンフィギュレーション オプション
システム モードの設定
Console では、次を選択できます。
• システムの動作モード
• 非対称ルーティング分類モード
システム モードについての情報
• 「システムの動作モード」
• 「非対称ルーティング分類モード」
システムの動作モード
システムの動作モードは、システムがネットワーク トラフィックを処理する方法を定義します。
(注) 各規則には独自の動作モード(状態)があります。これがシステム モードと異なる場合、2 つのモードのうち「下位」のモードが使用されます。たとえば、規則が有効で、システム モードが Report Only の場合、規則は RDR の生成だけを行います。
3 つの動作モードは次のとおりです。
• Full Functionality:システムはアクティブな規則をネットワーク トラフィックに適用し、レポート機能を実行します(つまり、RDR を生成します)。
• Report Only:システムは RDR の生成だけを行います。ネットワーク トラフィックには、アクティブな規則は適用されません。
• Transparent:システムは RDR を生成せず、ネットワーク トラフィックにアクティブな規則を適用しません。
非対称ルーティング分類モード
単一方向のフロー レートが高い環境に SCE プラットフォームが配置されている場合、単方向分類モードを有効にすると分類の精度を大幅に向上させることができます。
• 「サポートされない機能」
• 「プロトコル分類」
• 「非対称ルーティング分類モードへの切り替え」
• 「非対称ルーティング分類モードからの切り替え」
サポートされない機能
単方向分類が有効になっている場合、SCA BB の次の機能が使用できません。
• フレーバ
• 外部クォータ プロビジョニング
• サブスクライバ通知
• リダイレクション
• Flow Signaling RDR
• コンテンツ フィルタリング
• VAS トラフィック フォワーディング
単方向分類が有効になっている場合、Service Configuration Editor には([Problems View] に)サービス コンフィギュレーションとこのモードでサポートされる機能が一致するかどうかが表示されます。
次の機能はサービス コンフィギュレーションの一部ではありませんが、単方向分類が有効になっている場合に影響を受けます。
• サブスクライバアウェア モード(サブスクライバ情報が、現在サブスクライバが使用している IP アドレスに動的にバインドされるモード)は、サポートされていません。
• 拡張フロー オープン モードをイネーブルにする必要があります。
上記の機能の状態がルーティング分類モードの状態と一致するかどうかは表示されません。
プロトコル分類
単方向分類が有効になっている場合、プロトコル分類は単一方向の UDP フローを除いて通常の方法で実行されます。単一方向 UDP フローのサーバ側を知ることは不可能なので、SCA BB は先頭パケットの宛先ポートを使用してプロトコルを分類します。完全に一致するものが見つからなければ、送信元ポートを使用してプロトコルの分類を試みます。
非対称ルーティング分類モードへの切り替え
対称モードでサービス コンフィギュレーションを作成し、非対称ルーティング分類モードに切り替えると、次の状態になります。
• 分類にフレーバは使用されません。
• 定期的なクォータ管理モードが使用されます。
• 非対称ルーティング分類モードに切り替えてもデータは失われませんが、サポートされない機能をすべてサービス コンフィギュレーションから削除するまでは SCE プラットフォームにサービス コンフィギュレーションを適用できません。
非対称ルーティング分類モードからの切り替え
非対称ルーティング分類モードでサービス コンフィギュレーションを作成すると、次の状態になります。
• すべての異常ディテクタの不審セッション レートとセッション レートは同じに設定されます。
• デフォルト サービス コンフィギュレーションにフレーバは作成されず、サービス要素は指定されたフレーバを持ちません。
• クォータ管理モードは、集約時間が 1 日 1 回の定期モードになります。
• 対称モードに切り替えても非対称ルーティング分類モードの制限は保持されます。制限を変更するには、サービス コンフィギュレーションを編集する必要があります。
システムの動作モードとトポロジ モードの設定
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [System Settings] を選択します。
[System Settings] ダイアログボックスが表示されます(図 10-33)。
図 10-33 [System Settings]
ステップ 2 次の [System Operational Mode] オプション ボタンのうち 1 つを選択します。
• [Transparent]
• [Report Only]
• [Full Functionality]
ステップ 3 ルーティング分類モードを変更するには、[Enable the Asymmetric Routing Classification Mode] チェックボックスをオンまたはオフにします。
ステップ 4 [OK] をクリックします。
[System Settings] ダイアログボックスが閉じます。
新しいシステム モード設定が保存されます。
詳細サービス コンフィギュレーション プロパティ
表 10-3 に詳細サービス コンフィギュレーション プロパティを示します。
表 10-3 詳細サービス コンフィギュレーション プロパティ
|
|
|
[Classification] |
[Guruguru detailed inspection mode enabled] |
FALSE |
Guruguru プロトコルは、日本で普及している Guruguru ファイル共有アプリケーションで使用されます。SCA BB では、このプロトコルの分類に、次の 2 つの検査モードが提供されます。 • Default:Guruguru トラフィックが少ないことが予想されるネットワークに適しています。日本以外のすべての国ではこれが一般的です。 • Detailed:Guruguru トラフィックが一般的になることが予想されるネットワークに適しています。日本のネットワークだけで一般的です。 |
[Kuro detailed inspection mode enabled] |
FALSE |
Kuro プロトコルは、日本で普及している Kuro ファイル共有アプリケーションで使用されます。SCA BB では、このプロトコルの分類に、次の 2 つの検査モードが提供されます。 • Default:Kuro トラフィックが少ないことが予想されるネットワークに適しています。日本以外のすべての国ではこれが一般的です。 • Detailed:Kuro トラフィックが一般的になることが予想されるネットワークに適しています。日本のネットワークだけで一般的です。 |
[Soribada detailed inspection mode enabled] |
FALSE |
Soribada プロトコルは、日本で普及している Soribada ファイル共有アプリケーションで使用されます。SCA BB では、このプロトコルの分類に、次の 2 つの検査モードが提供されます。 • Default:Soribada トラフィックが少ないことが予想されるネットワークに適しています。日本以外のすべての国ではこれが一般的です。 • Detailed:Soribada トラフィックが一般的になることが予想されるネットワークに適しています。日本のネットワークだけで一般的です。 |
[TCP destination port signatures] |
1720:H323 |
正しい分類にポート ヒントが必要であるシグニチャの TCP 宛先ポート番号。 有効な値は、カンマで区切った項目です。各項目は <port-number>:<signature-name> という形式にします。 適用可能なシグニチャ名は、H323、Radius Access、Radius Accounting、および DHCP です。 |
[UDP destination port signatures] |
67:DHCP、68:DHCP、1812:Radius Access、1645:Radius Access、1813:Radius Accounting、1646:Radius Accounting |
正しい分類にポート ヒントが必要であるシグニチャの UDP 宛先ポート番号。 有効な値は、カンマで区切った項目です。各項目は <port-number>:<signature-name> という形式にします。 適用可能なシグニチャ名は、H323、Radius Access、Radius Accounting、および DHCP です。 |
[UDP ports for which flow should be opened on first packet] |
5060、5061、67、68、69、1812、1813、1645、1646、2427、2727、9201、9200、123、1900、5190、10000 |
拡張フローオープン モードは指定 UDP ポートで無効になり、フローの先頭パケットに従った分類が可能になります。 |
[UDP source port signatures] |
1812:Radius Access、1645:Radius Access、1813:Radius Accounting、1646:Radius Accounting |
正しい分類にポート ヒントが必要であるシグニチャの UDP 送信元ポート番号。 有効な値は、カンマで区切った項目です。各項目は <port-number>:<signature-name> という形式にします。 適用可能なシグニチャ名は、H323、Radius Access、Radius Accounting、および DHCP です。 |
[V-Share detailed inspection mode enabled] |
FALSE |
V-Share プロトコルは、日本で普及している V-Share ファイル共有アプリケーションで使用されます。SCA BB では、このプロトコルの分類に、次の 2 つの検査モードが提供されます。 • Default:V-Share トラフィックが少ないことが予想されるネットワークに適しています。日本以外のすべての国ではこれが一般的です。 • Detailed:V-Share トラフィックが一般的になることが予想されるネットワークに適しています。日本のネットワークだけで一般的です。 |
[Winny detailed inspection mode enabled] |
FALSE |
Winny P2P プロトコルは、日本で普及している Winny ファイル共有アプリケーションで使用されます。SCA BB では、このプロトコルの分類に、次の 2 つの検査モードが提供されます。 • Default:Winny トラフィックが少ないことが予想されるネットワークに適しています。日本以外のすべての国ではこれが一般的です。 • Detailed:Winny トラフィックが一般的になることが予想されるネットワークに適しています。日本のネットワークだけで一般的です。 |
[Malicious Traffic] |
[Malicious Traffic RDRs enabled] |
TRUE |
悪質トラフィック RDR を生成するかどうかを指定します。 |
[Number of seconds between Malicious Traffic RDRs on the same attack] |
60 |
攻撃が検出されると、悪質トラフィック RDR が生成されます。悪質トラフィック RDR は、攻撃が続く間、ユーザが設定した間隔で定期的に生成されます。 |
[TCP port that should remain open for Subscriber Notification] |
80 |
検出されたネットワーク攻撃の一部であるフローのブロックを選択できますが、これによって攻撃のサブスクライバ通知が妨害されることがあります。 指定 TCP ポートはブロックされず、攻撃通知をサブスクライバに送信できるようになります。 |
[Policy Check] |
[Ongoing policy check mode enabled] |
TRUE |
すでに開いているフローにポリシーの変更が影響するかどうかを指定します。 |
[Time to bypass between policy checks] |
30 |
すでに開いているフローにポリシーの変更が影響する前に経過する最長時間(秒単位)。 |
[Quota Management] |
[Grace period before first breach] |
2 |
クォータ制限違反があったあと、違反処理を実行する前に待機する時間(秒単位)。 ポリシー サーバではこの時間を使用し、ログインしたサブスクライバにクォータをプロビジョニングします。 |
[Length of the time frame for quota replenish scatter (minutes)] |
0 |
定期クォータ補充をランダムに分散する時間帯の長さ。 |
[Time to bypass between policy checks for quota limited flows] |
30 |
すでに開いているフローにクォータ違反が影響する前に経過する最長時間(秒単位)。 |
[Volume to bypass between policy checks for quota limited flows] |
0 |
すでに開いているフローにクォータ違反が影響する前に通過する最大フロー ボリューム(バイト単位)。 値をゼロにすると、ボリュームが無制限に通過します。 |
[Reporting] |
[Media Flow RDRs enabled] |
TRUE |
メディア フロー RDR を生成するかどうかを指定します。 |
[Subscriber Accounting RDR enabled] |
FALSE |
サブスクライバ課金 RDR を生成するかどうかを指定します。 サブスクライバ課金 RDR は、SM-ISG 統合に使用します。詳細については、『 Cisco SCE8000 10GBE Software Configuration Guide 』の「Managing the SCMP」の章にある ISG 文書または『 Cisco SCE8000 10GBE Software Configuration Guide 』の「Managing the SCMP」の章を参照してください。 |
詳細サービス コンフィギュレーション オプションの編集
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [System Settings] を選択します。
[System Settings] ダイアログボックスが表示されます。
ステップ 2 [Advanced Options] タブをクリックします。
[Advanced Options] タブが開きます(図 10-34)。
図 10-34 [Advanced Options] タブ
ステップ 3 [Advanced Service Configuration Options] をクリックします。
[Advanced Service Configuration Options] ダイアログボックスが開きます(図 10-35)。
図 10-35 [Advanced Service Configuration Options]
ステップ 4 設定オプションを変更します。
ステップ 5 [OK] をクリックします。
[Advanced Service Configuration Options] ダイアログボックスが閉じます。
詳細オプションの変更が保存されます。
ステップ 6 [OK] をクリックします。
[System Settings] ダイアログボックスが閉じます。
VAS 設定の管理
Value Added Service(VAS)設定には、次の機能が含まれます。
• トラフィック ミラーリング:トラフィック ミラーリングでは、SCE を使用してそのアプリケーションおよびサブスクライバ アウェアネスに基づいてトラフィックの一部をミラーリングできます。ミラーリング対象のトラフィックはそのままフォワーディングされ、パケットの複製は、対応する VAS の VLAN に送信されます。つまり、トラフィックは、最小化されます。
• トラフィック フォワーディング:トラフィック フォワーディング サーバでは、外部エキスパート システム(VAS サーバ)を使って侵入検知やサブスクライバのコンテンツ フィルタリングなどのトラフィック処理を追加できます。フローは処理後に SCE プラットフォームに送り返され、SCE プラットフォームはフローを元の宛先に送信します。
フォワーディングされるフローは、サブスクライバ パッケージおよびフロー タイプ(IP プロトコル タイプおよび宛先ポート番号)に基づいて選択されます。
VAS ミラーリングには、次の制限があります。
• SCE 2000 および SCE8000 は、いずれもトラフィック ミラーリングをサポートします。
• トラフィック ミラーリングは、少なくとも 2 つのポートを備える任意の SCE プラットフォームでサポートされます。
• SCE8000 は、64 の VLAN を備えることができます。
• SCE 2000 は、8 の VLAN を備えることができます。
VAS フォワーディングには、次の制限があります。
• SCE 2000 4xGBE プラットフォームだけが VAS トラフィック フォワーディングをサポートします。
• 1 つの SCE プラットフォームでは、最大 8 の VAS サーバをサポートできます。
• サービス コンフィギュレーションには、最大 64 のトラフィックフォワーディング テーブルを含めることができます。
• トラフィックフォワーディング テーブルには、最大 64 のテーブル パラメータを含めることができます。
• 単方向分類が有効になっている場合、VAS トラフィック フォワーディングはサポートされません。
(注) VAS 設定機能は複雑なので、VAS フローはグローバル帯域幅制御に影響されません。
VAS トラフィックフォワーディングを使用するには、SCE プラットフォームで VAS サービスを設定する必要もあります。詳細については、『 Cisco SCE2000 and SCE1000 Software Configuration Guide 』の「Value Added Services (VAS) Traffic Forwarding」の章を参照してください。
• 「VAS トラフィック フォワーディングの有効化」
• 「VAS サーバ グループの名前変更」
• 「VAS トラフィックフォワーディング テーブルの表示」
• 「VAS トラフィックフォワーディング テーブルの削除」
• 「VAS トラフィックフォワーディング テーブルの追加」
• 「VAS テーブル パラメータの管理」
VAS トラフィック フォワーディングの有効化
デフォルトの場合、VAS トラフィック フォワーディングは無効になっています。VAS トラフィック フォワーディングはいつでも有効にすることができます。
(注) 単方向分類が有効になっている場合、VAS トラフィック フォワーディングはサポートされません。
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [VAS Settings] を選択します。
[VAS Settings] ダイアログボックスが表示されます(図 10-36)。
図 10-36 [VAS Settings]
ステップ 2 [Enable Traffic Forwarding] オプション ボタンをオンにします。
(注) VAS トラフィック フォワーディングは、非対称ルーティング分類モードではサポートされません。非対称ルーティング分類モードが有効のときに [Enable Traffic Forwarding] オプション ボタンをオンにしようとした場合は、VAS のエラー メッセージが表示されます。
[OK] をクリックし、ステップ 4 に進みます。
VAS の警告メッセージが表示されます。
ステップ 3 [OK] をクリックします。
ステップ 4 [Close] をクリックします。
[VAS Settings] ダイアログボックスが閉じます。
VAS トラフィック ミラーリングの有効化
トラフィック ミラーリングは、[VAS Setting] ダイアログボックスで有効化と設定を行います。しかし、使用するサーバ グループは、規則を定義するときに設定します。
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [VAS Settings] を選択します。
[VAS Settings] ダイアログボックスが表示されます。
ステップ 2 [Enable Traffic Mirroring] オプション ボタンをオンにします。
VAS の警告メッセージが表示されます。
ステップ 3 [OK] をクリックします。
ステップ 4 [Close] をクリックします。
[VAS Settings] ダイアログボックスが閉じます。
VAS サーバ グループの名前変更
SCE プラットフォームでは、最大 8 個の VAS サーバ グループにフローを転送できます。デフォルトでは、この 8 個のサーバ グループは「Server Group n」という名前です(n は、0 ~ 7 の値)。サーバ グループにわかりやすい名前を指定すると、指定した名前が [Add Rule to Package] ダイアログボックスの [Control and Breach Handling] タブのドロップダウン リスト(「高度なパッケージ オプションの設定」を参照)と各トラフィックフォワーディング テーブルに追加されたテーブル パラメータの [Server Group] フィールド(「VAS テーブル パラメータの管理」を参照)に表示されます。
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [VAS Settings] を選択します。
[VAS Settings] ダイアログボックスが表示されます(図 10-37)。
ステップ 2 [Server Groups Table] 領域のテーブルで、サーバ グループ名を含むセルをダブルクリックします。
ステップ 3 わかりやすい名前をセルに入力します。
ステップ 4 名前を変更する他のサーバ グループについてもステップ 2 およびステップ 3 を繰り返します。
図 10-37 [Traffic Forwarding Groups] タブ
ステップ 5 [Close] をクリックします。
[VAS Settings] ダイアログボックスが閉じます。
VAS トラフィック ミラーリングの有効化
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [VAS Settings] を選択します。
[VAS Settings] ダイアログボックスが表示されます(図 10-38)。
図 10-38 [Traffic Mirroring Groups] タブ
ステップ 2 [Enable Traffic Forwarding] オプション ボタンをクリックします。
ステップ 3 各サーバ グループについて、[Flow Volume to Mirror (KB)] カラムにミラーリングの最大量(KB 単位)を入力します。
ステップ 4 [Close] をクリックします。
[VAS Settings] ダイアログボックスが閉じます。
VAS トラフィックフォワーディング テーブルの表示
SCA BB は、SCE プラットフォームを通過するフローを VAS サーバ グループに転送するかどうかをトラフィックフォワーディング テーブルに基づいて判断します。トラフィックフォワーディング テーブルの各エントリ(テーブル パラメータ)では、特定フローをどの VAS サーバ グループに転送するかが定義されます。
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [VAS Settings] を選択します。
[VAS Settings] ダイアログボックスが表示されます。
ステップ 2 [Enable Traffic Forwarding] オプション ボタンをクリックします。
ステップ 3 [Traffic Forwarding Tables] タブをクリックします。
[Traffic Forwarding Tables] タブが開きます。
すべてのトラフィックフォワーディング テーブルのリストが、[Traffic Forwarding Tables] 領域に表示されます。
ステップ 4 トラフィックフォワーディング テーブルのリストのテーブルをクリックし、テーブル パラメータを表示します。
トラフィックフォワーディング テーブルに定義されているすべてのテーブル パラメータのリストが、[Table Parameters] タブに表示されます(図 10-39)。
図 10-39 [Traffic Forwarding Tables] タブ
ステップ 5 [Close] をクリックします。
[VAS Settings] ダイアログボックスが閉じます。
VAS トラフィックフォワーディング テーブルの削除
ユーザが作成したすべてのトラフィックフォワーディング テーブルを削除できます。デフォルト トラフィックフォワーディング テーブルを削除することはできません。
(注) パッケージに関連しているトラフィックフォワーディング テーブルを削除することはできません。
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [VAS Settings] を選択します。
[VAS Settings] ダイアログボックスが表示されます。
ステップ 2 [Enable Traffic Forwarding] オプション ボタンをクリックします。
ステップ 3 [Traffic Forwarding Tables] タブをクリックします。
[Traffic Forwarding Tables] タブが開きます。
ステップ 4 [Traffic Forwarding Tables] 領域のトラフィックフォワーディング テーブルのリストからテーブルを選択します。
ステップ 5 ([Delete])をクリックします。
[VAS Warning] メッセージが表示されます(図 10-40)。
図 10-40 [VAS Warning]
ステップ 6 [Yes] をクリックします。
選択したテーブルが削除され、トラフィックフォワーディング テーブルのリストに表示されなくなります。
ステップ 7 [Close] をクリックします。
[VAS Settings] ダイアログボックスが閉じます。
VAS トラフィックフォワーディング テーブルの追加
サービス コンフィギュレーションにはデフォルト トラフィックフォワーディング テーブルが組み込まれています。最大 63 のトラフィックフォワーディング テーブルをさらに追加し、さまざまなトラフィックフォワーディング テーブルを別々のパッケージに割り当てることができます。
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [VAS Settings] を選択します。
[VAS Settings] ダイアログボックスが表示されます。
ステップ 2 [Enable Traffic Forwarding] オプション ボタンをクリックします。
ステップ 3 [Traffic Forwarding Tables] タブをクリックします。
[Traffic Forwarding Tables] タブが開きます。
ステップ 4 [Traffic Forwarding Tables] 領域で ([Add])をクリックします。
「Table (n)」( n は 1 ~ 63 の値)という名前の新しいテーブルが、[Traffic Forwarding Tables] 領域のトラフィックフォワーディング テーブルのリストに追加されます。
テーブル名は、[Table Parameters] タブの [Item Name] ボックスにも表示されます。
ステップ 5 トラフィックフォワーディング テーブルの一意でわかりやすい名前を [Item Name] フィールドに入力します。
新しいトラフィックフォワーディング テーブルにはテーブル パラメータを追加できます(「VAS テーブル パラメータの追加」を参照)。
VAS テーブル パラメータの追加
最大 64 のテーブル パラメータをトラフィックフォワーディング テーブルに追加できます。
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [VAS Settings] を選択します。
[VAS Settings] ダイアログボックスが表示されます。
ステップ 2 [Enable Traffic Forwarding] オプション ボタンをクリックします。
ステップ 3 [Traffic Forwarding Tables] タブをクリックします。
[Traffic Forwarding Tables] タブが開きます。
ステップ 4 [Traffic Forwarding Tables] 領域のトラフィックフォワーディング テーブルのリストからテーブルを選択します。
ステップ 5 [Traffic Parameters] タブで、 ([Add])をクリックします。
[Table Parameters] タブのテーブル パラメータのリストに、新しいテーブル パラメータが追加されます。
(注) それぞれの新しいテーブル パラメータには、表 10-4 に示されるデフォルト値が含まれます。
表 10-4 テーブル パラメータのデフォルト値
|
|
[IP Protocol] |
TCP Port |
[TCP/UDP Port] |
80 |
[Server Group] |
Server Group 0 |
次のセクションで説明するように、新しいテーブル パラメータをここで編集できます。
ステップ 6 [Close] をクリックします。
[VAS Settings] ダイアログボックスが閉じます。
VAS テーブル パラメータの編集
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [VAS Settings] を選択します。
[VAS Settings] ダイアログボックスが表示されます。
ステップ 2 [Enable Traffic Forwarding] オプション ボタンをクリックします。
ステップ 3 [Traffic Forwarding Tables] タブをクリックします。
[Traffic Forwarding Tables] タブが開きます。
ステップ 4 [Traffic Forwarding Tables] 領域のトラフィックフォワーディング テーブルのリストからテーブルを選択します。
ステップ 5 [Table Parameters] タブのテーブルで、プロトコル、ポート、およびサーバ グループを選択します。
a. [IP Protocol] カラムのセルをクリックし、表示されるドロップダウン リストから IP プロトコル タイプを選択します(図 10-41)。
図 10-41 [Table Parameters] タブ
[All]、[All TCP]、[All UDP]、[All Non TCP/UDP] のうちいずれかを選択した場合は、テーブルの別のセルに移動すると、TCP/UDP Port セルに「N/A」と表示されます。
b. [TCP Port] または [UDP Port] を選択した場合は、[TCP/UDP Port] カラムのセルをダブルクリックし、ポート番号を入力します。
(注) ポートの範囲を [TCP/UDP Port] セルに入力することはできません。ポートごとに別のテーブル パラメータを追加する必要があります。
c. [Server Group] カラムのセルをクリックし、表示されるドロップダウン リストからサーバ グループを選択します(図 10-42)。
図 10-42 [Tables Parameters] タブ
ステップ 6 [Close] をクリックします。
[VAS Settings] ダイアログボックスが閉じます。
VAS テーブル パラメータの削除
ステップ 1 左のペインの [Policies] タブで、[Configuration] > [VAS Settings] を選択します。
[VAS Settings] ダイアログボックスが表示されます。
ステップ 2 [Enable Traffic Forwarding] オプション ボタンをクリックします。
ステップ 3 [Traffic Forwarding Tables] タブをクリックします。
[Traffic Forwarding Tables] タブが開きます。
ステップ 4 [Traffic Forwarding Tables] 領域のトラフィックフォワーディング テーブルのリストからテーブルを選択します。
ステップ 5 [Table Parameters] タブのテーブル パラメータのリストからテーブル パラメータを選択します。
ステップ 6 ([Delete])をクリックします。
選択したテーブル パラメータが削除され、テーブル パラメータのリストに表示されなくなります。
ステップ 7 [Close] をクリックします。
[VAS Settings] ダイアログボックスが閉じます。