カテゴリー別アーカイブ: TIPs

運用で活用すると便利なケースと設定についてです。

GenieATMではSNMPが必要ですか? 使う/使わないでどのような違いがありますか?

GenieATMはSNMPでルータと設定やトラヒック情報のやり取りを行います。SNMPの利用は必須ではありませんが、以下の理由でご利用をおすすめします。

SNMPを利用するとできること

  • ルータのインターフェース登録が容易に行えます。SNMPを使わない場合は個別に手動での登録が必要です。
  • ルータのインターフェース毎のトラヒックレポートがxFlowとSNMP(IF MIB)の両方で作成できます。これにより双方が比較できて、ルータ側のxFlow設定の不足等が見つけやすくなります。
  • インターフェースの利用率やパケット廃棄等の検知が行えます。
    • xFlowでもトラヒック量の監視は可能です。
    • SNMP で可能なインターフェースの監視項目:CRCエラー、インターフェース利用率、パケット廃棄、マルチキャスト&ブロードキャストトラヒック割合
  • ルータのCPUとメモリの使用率のレポート作成が可能です。

特定のネットワークのトラヒックについてASパス分析をしたい

監視対象のネットワークにおいて、特定のネットワークのトラヒックについてASパスの分析をする場合です。
ここでは特定のネットワークをサブネットワークとして設定しています。
サブネットワークへの入力方向と出力方向のトラヒックを別々のレポートとして作成しています。
入力と出力を同一レポートに含めることも可能ですが、見難くなるので別個のレポートにしています。

DNS オープンリゾルバを検知したい

アプリケーション異常で検知可能です。

Webの システム管理 > ネットワーク > 異常状態 > [tab]アプリケーション異常 にて新規設定を追加します。
攻撃タイプを”ワーム”にしてください。
ベースラインが閾値になります。この例だとDNSクエリの応答パケット(送信元ポート udp/53)が 500pps を超えると検知します。値は調整してください。

openresolverconf

検知スコープが”ホーム”の場合、発信元がホームネットワークに該当する場合に検知対象となります。
(ホームネットワークは システム管理 > ネットワーク > ホームネットワーク で設定します)

openresolverconf2

設定後、ディスパッチを行います。
(システム管理 > 構成 にて実施)

閾値をこえるDNSクエリへの応答パケットが発生した場合、このように検知します。
(画面例はテストのため閾値を低くしています)

resolver

anomaly-resolver1

特定のセグメントについてホスト毎やAS毎にトラヒック分類したい

特定のセグメントのなかに大量の通信を行っているホストやASを継続して可視化したいという場合は、サブネットワークを利用すると便利です。

ホスト毎であればトップトーカーを使うと便利です。
AS毎であればOrigin ASNレポートが便利です。

下記スライドの”SUB-NETWORK TRAFFIC ANALYSIS”を参考にしてください。

ISPが使うと便利なAS分析の設定について

運用で便利なAS分析レポートの例です。
末尾のスライドにレポート画面例とその設定例があります。

  1. オリジンAS毎のトラヒック分類
    • 自網全体のトラヒックについてのAS分析ができます。
  2. ピアAS毎のトラヒック分類
    • ピアAS毎のトラヒック量が見えます。各ピアの評価に便利です。
  3. ピアリング評価のためのピアリング分析
    • 各ピアにおいて、通過(トランジット)しているトラヒックとピア先と直接交換しているトラヒックの割合について見えます。トランジットの評価に便利です。
  4. ネイバー毎のオリジンAS分析
    • 2.はネイバー毎のトラヒック総量をグラフ化しますが、こちらはその各ネイバーについてのオリジンASのトラヒック分類を行います。特定ASのトラヒックを異なるトランジット先に移動させたい等の計画に便利です。
  5. ASパス毎のトラヒック分類
    • 大きなトラヒックのうち、ASパスが長いものを抽出できます。ピアリングの見直しに役立ちます。

 

 

バージョンアップ後のGUI異常動作

GenieATMのソフトウェアアップグレードを行ったあと,GUIからの操作がうまく動作しないことがあります。
たとえば,以下のようなケースです。

  • 「ルータの追加」ページ(システム管理 > ネットワーク > ルータ)から新しいルータを登録して「実行」ボタンを押したのに,一覧画面に戻ったら追加されていなかった
  • 「プロトコル不正使用管理」ページ(システム管理 > ネットワーク > 異常状態 > プロトコル不正使用 タブ)で閾値を編集して「実行」ボタンを押したら”Please Input event threshold value!”というエラーメッセージが出た

これらは,ウェブ・ブラウザがキャッシュに残ったアップグレード前のページを読み込んでいることが原因の場合があります。ブラウザでスーパーリロードを行うことでバージョンアップ後のページを読み込んでから,もう一度試してみてください。スーパーリロードは,以下の操作で行えるようです。

プラットフォーム オペレーション
Windows Ctrl + F5 (IE,Firefox,Chrome)
Shift + 更新ボタン (Safari)
Mac Command + R (Chrome, Safari, Opera)

※GenieATMは上記のすべてのブラウザでの動作を保証しているわけではありません。

デバイス連携のミチゲーションポリシーが発動しない

GenieATMはA10 Thunder TPSやRadware DefensePro等のミチゲーションデバイスと連携してDDoS攻撃を防御する機能を持っています。
ブラックホールポリシーと同様のミチゲーションポリシーをあらかじめ定義しておき,特定のホストへの攻撃を検知したときに当該ホストへのトラフィックへの経路をミチゲーションデバイスに向けることで防御を行います。

ミチゲーション動作の仕組み

デバイス連携の自動ミチゲーションを有効にしていたにもかかわらず,防御対象のIPアドレスに対する攻撃が検出されたときに,ポリシーが発動しない場合があります。その場合,すでに発動中のミチゲーションアクションによりポリシーに設定したデバイスの帯域が埋まっている可能性があります。

ミチゲーションデバイス連携ポリシーの設定画面には,下のような帯域設定項目があります。これは,デバイスのキャパシティを超えて異常トラフィックが流れ込まないようにするための機能です。

ミチゲーションポリシーの帯域設定

例えば,帯域を1Gbpsに設定しているデバイスに現在発動中のミチゲーションにより合計1Gbps超のトラフィックがすでに流入している場合,当該デバイスについて新たなミチゲーションは発動されません。ただし,ブラックホールポリシーなどほかのタイプのポリシーが定義されている場合は,そちらが発動します。

関連トピック

Blackholeポリシーが機能しない

レポート再構成時のRawdata存在判定

レポート再構成機能(システム管理 > レポート再構成)の「Step 2.時間間隔と対象コレクターの指定」において対象日付範囲を指定するダイアログボックスがあります。ここには,コレクターごとに各日付のRawdata存在状況が,No Data,Incomplete Data,Complete Dataの3種類の色分けで表示されます。

レポート再構成時の日付範囲指定ダイアログ

この判定は,1分ごとにディスク上に作成されるRawdataファイルに基づいて以下のように行われます。

種別 条件
No Data 毎時0分,5分,10分…のRawdataファイルが一つも存在しない
Incomplete Data 毎時0分,5分,10分…のRawdataファイルのうち1つでも存在しないものがある
Complete Data 毎時0分,5分,10分…のRawdataファイルがすべて存在する

従って,正常にフローレコードを受信し続けている場合でも,トラフィックの落ち込んだ時間帯にRawdataファイルが作成されないことがあるとIncomplete Dataと判定されることになりますので,あくまでも目安としてお考えください。なお,Rawdataファイルの一覧は,CLIよりshow rawdataコマンドで見ることができます。

show rawdata {internal | nfs} [ from <from-datetime> to <to-datetime> ]

フローレコード受信の確認

GenieATMに新たなエクスポータの定義を追加したのにスナップショットやレポートでトラフィックが表示されない場合の標準的なご確認項目,切り分け方法をご紹介します。

  1. ネットワーク到達性
  2. ファイヤーウォール
  3. フローパケットの到達

1. ネットワーク到達性

CLIのEnableモードよりpingコマンドでエクスポータとのネットワーク到達性を確認します。

ATM90 # ping 172.16.2.224
PING 172.16.2.224 (172.16.2.224) 56(84) bytes of data.
64 bytes from 172.16.2.224: icmp_req=1 ttl=64 time=1.53 ms
64 bytes from 172.16.2.224: icmp_req=2 ttl=64 time=0.411 ms
64 bytes from 172.16.2.224: icmp_req=3 ttl=64 time=0.422 ms
^C
--- 172.16.2.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.411/0.790/1.538/0.529 ms
ATM90 #

(Ctrl+Cで停止します)

2. ファイヤーウォール

CLIのEnableモードよりshow runningコマンドによりaccess groupfirewall enableの設定を表示し,エクスポータからフロー受信ポートへのUDPパケットがブロックされていないことを確認します。

ATM90 # show running
#### show running configure ####
!
!
  hostname ATM90
  clock timezone JST +9
  ip domain-name jp.genie-networks.com
!
interface ethernet 0
  ip address 172.16.2.90 255.255.255.0
  ip address 172.16.2.92 255.255.255.0 secondary
!
   :
  (中略)
   :
  ip route 0.0.0.0 0.0.0.0 172.16.2.1 0
  access group 172.16.0.0 netmask 255.255.0.0 protocol ip permit
  firewall enable
  module id collector 3001
   :
  (中略)
   :
!
ATM90 #
3. フローパケットの到達

flow dumpコマンドをsrc hostにエクスポータのIPアドレスを指定して実行し,フローレコードが届いているかを確認します。

ATM90 (debug)# flow dump
Please input nfdump parameters and press return
-a "src host 172.16.2.224"
Do you want to add "more" command behind the nfdump
parameters to prevent terminal session crashed?(Y/N) y
nfdump: listening on device eth0
expression: src host 172.16.2.224
11:04:23  172.16.2.224.8888 > 172.16.2.90.6343 : sflow ver = 4, count = 1, len = 224
 -----------------------------------------------------------------------
| version         | ip_ver          | agent_addr      | seq_number      |
| 4               | 1               | 172.16.2.224    | 61884802        |
 -----------------------------------------------------------------------
| switch_uptime   | count           |
| 1190572734      | 1               |
------------------------------------
flow      1 sample_type         1                     seq_number          84086197
sample      src_id_type         0                     src_index_value     33
            sampling_interval   256                   sample_pool         51229952
            drops               0                     input               33
            output              0                     packet_data_type    1
            header_protocol     1                     frame_length        1466
            length_of_header    128                   Destination         29:73:08:0c:34:e3
            Source              03:d7:55:2b:21:c0     type                0x8100
            priority            0                     CFI                 0
            id                  102                   type                0x800
            version             4                     header_length       20
            tos                 0x0                   total_length        1444
            id                  0x44cc                flag                0x0
            flag_offset         0x0                   time_to_live        254
            protocol            0x11                  checksum            0x5538
            source ip address   10.144.8.2            dest ip address     172.16.2.149
            source port number  56488                 dst port number     2055
            udp_length          1424                  udp_checksum        0x5ea5
            data                82        bytes
            n_extended_data     1
            extened_data_type   1                     src vlan            102
            src priority        0                     dest vlan           0
            dest priority       0

            -------------------------------------------------------------------------------------
11:04:24  172.16.2.224.8888 > 172.16.2.90.6343 : sflow ver = 4, count = 1, len = 216
 -----------------------------------------------------------------------
| version         | ip_ver          | agent_addr      | seq_number      |
| 4               | 1               | 172.16.2.224    | 61884803        |
 -----------------------------------------------------------------------
| switch_uptime   | count           |
| 1190573744      | 1               |
------------------------------------
flow      1 sample_type         1                     seq_number          6101417
sample      src_id_type         0                     src_index_value     30
            sampling_interval   256                   sample_pool         1561962752
            drops               0                     input               30
            output              0                     packet_data_type    1
ATM90 (debug)#

上記の例ではsFlowバージョン4のフローサンプルレコードが届いていることが分かります。

確認ポイント

  • sFlowのヘッダにはAgentアドレス(上記の結果のagent addr)という項目があります。これがGenieATMのエクスポータ定義の「フローエクスポータIPアドレス」と一致していなければなりません。フローの送信元IPアドレスとは異なる場合がありますのでご注意ください。
  • ヘッダにフローレコード数の項目(count)があります。NetFlowバージョン9は1つのフローパケットに複数のフローセットが含まれ,1つのフローセットに複数のフローレコードが含まれるという2階層構造を持ちます。count項目にはフローセットではなくフローレコードの総数が入っている必要があり,GenieATMはこの項目が適切に設定されていないと当該フローパケットを正しく解析することができません。