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

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

WannaCry攻撃の監視・警告

TIPs

2017年5月、WannaCryは脅威的な感染スピードで200カ国以上のコンピュータが150カ国に感染しました。（5月18日現在）
WannaCryは米国国家安全保障局（NSA）によって開発され、ユーザーシステムに浸透している「EternalBlue」と呼ばれるMicrosoft Server Message Block 1.0 (SMBv1) の脆弱性を標的にしています。

本稿では、GenieATMが 世界的に最大規模のサービスプロバイダーでWannaCry攻撃を効果的に監視し、警告するのを支援した事例を紹介いたします。

WannaCryのネットワーク特性

WannaCryは、SMBの脆弱性を悪用してRPC攻撃を行うランサムウェアです。

通常、ランサムウェアはWindows NetBIOSの名前解決とSMBが使用するポート(※1)を攻撃します。

WannaCryは、脆弱なポートへの接続が成功するとシステムへの感染と暗号化を進めます。
さらに、サブネットワーク（/24）をスキャンし、他の脆弱なシステムを探します。

そのため、WannaCryが感染活動をしている間、ネットワーク上でこれらのポートへの大量なトラフィックが確認されます。

※1：135/tcp, 137/tcp, 139/tcp, 455/tcp, 137/udp, 138/udp

GenieATMの監視と警告

GenieATMは、リアルタイムなトラフィック分析とセキュリティ保護を提供するように設計されたフローベースのトラフィック分析ソリューションです。

このシステムには、リアルタイムのプロファイラが搭載されており、トラフィックの動作を分析します。
疑わしいトラフィックが検出されると、GenieATMは組み込みシグネチャと異常データベースを相互に照合し、タイムリーにネットワークオペレータに警告します。

GenieATMは、標準のままでネットワークインフラストラクチャ全体からWannaCryのような攻撃トラフィックを監視できます。

さらにGenieATMは、通常のトラフィックレートから逸脱したSMBトラフィックを詳細に監視・警告することもできます。
GenieATMはWannaCryの感染活動によるトラフィックについて完全な属性レポート（※2）を提供し、ユーザーに攻撃の拡散に関する洞察を提供します。
これにより、WannaCry攻撃を正しく防御することが可能になります。

※2：属性レポート

WannaCryが攻撃するポートに関して
・プロトコル
・送信元/先IPアドレス
・送信元/先ポート
・送信元/先インターフェス
などを組み合わせて任意のレポートが可能です。
これにより攻撃トラフィックの多いポートや攻撃・被害ホストを容易に把握することができます。

世界的に最大規模のサービスプロバイダーでは

GenieATMを使用していたため、WannaCryの活動がはじまったとき、WannaCryのネットワーク特性の通信ポート上のトラフィック異常を検知していました。
これらサービスプロバイダでは、WannaCryがネットワーク上でピークに達していた頃には、TCPポート445のトラフィックは、通常のトラフィックレートの3倍～4倍にまで増加していました。

WannaCry攻撃を詳細に監視するためにGenieATMで属性レポートを使用し、攻撃・被害ホストの特定および警告を行うように構成しました。
これにより、WannaCry攻撃は政府機関、大学、データーセンター、データセンターネットワークソリューション(DCN)など多岐に渡っていることが確認されました。
また、攻撃・被害ホストの特定により攻撃を正しく防御できました。

WannaCry攻撃を詳細に監視するための属性レポートの設定例

前述のサービスプロバイダーがWannaCry攻撃を監視したときに使用した属性レポートの設定方法を以下に記載します。

１．アプリケーションシグネチャの追加

[ システム管理 > ネットワーク > アプリケーション ]にて”アプリケーションの追加”を行う。

WannaCryが攻撃に使用するポートを登録する。（例では135番, 137番, 138番, 139番, 455番をUDP/TCPともに登録している）

2. 属性レポートを作成する

[ システム管理 > ネットワーク > フィルタ ]の”フィルタ”タブから”追加”する。

例では、ホームネットワークからインターネットに出ていくWannaCryの攻撃（※3）について

  • 送信元IPv4→送信先IPv4・送信先プロトコル／ポート
  • 送信先IPアドレス・出力インターフェース

の属性レポートを生成する。

GenieATMでは新しく定義した属性レポートを過去（※4）に遡ってレポート作成する”レポート再構成”機能があります。

”レポート再構成”により新しい観点（属性）や条件（ファクタ）で事象（WannaCryアウトブレーク時など）を解析しなおすことが可能です。

※3: ホームネットワークからインターネットに出ていくWannaCryの攻撃は、

  • 「スコープ: 境界 “Internet Boundary”」にて境界I/F
  • “表記（ファクタ）”
    • 「Src. IP＝HOME」にてホーム→インターネット
    • 「Dst. App.=WannaCry.attack」にてWannaCryが攻撃するポート
      • 1.で定義したアプリケーションシグネチャ

を特定している。

※4: データを保持している期間分はレポートの再構成が可能

詳しくは レポート再構成時のRawdata存在判定 を参照

まとめ

今回のWannaCryの攻撃からGenieATMがお客様のネットワークインフラストラクチャを保護できたことからも、WannaCryのような破壊的な危機に備えて、常にネットワークの監視を行うことは非常に重要です。

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

TIPs, 機能, 設定

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

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

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

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

TIPs, 設定

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

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

TIPs,

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

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

openresolverconf

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

openresolverconf2

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

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

resolver

anomaly-resolver1

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

TIPs, ,

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

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

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

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

TIPs, ,

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

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

 

 

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

TIPs, ,

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

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

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

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

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

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

TIPs, , ,

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

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

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

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

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

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

関連トピック

Blackholeポリシーが機能しない

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

TIPs, ,

レポート再構成機能（システム管理 > レポート再構成）の「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> ]