ログ分析・監視テクニック

nProbeであらゆる通信をログに記録し可視化する

当記事では、ジュピターテクノロジー株式会社様が国内で販売するntop社のnProbeを用いて、NetFlowを生成/収集し、LAN内の通信を含め、あらゆる通信をログに記録し可視化する方法について記載しています。

nProbeについては、ジュピターテクノロジー株式会社様のWebサイトをぜひご覧ください。

高速NetFlowプローブの決定版 nProbe – ジュピターテクノロジー株式会社 (jtc-i.co.jp)

また、nProbeはジュピターテクノロジー株式会社様より評価ライセンスを入手することができます。

評価ライセンスの入手方法や評価環境の構築方法については以下のページから、「評価ガイド」をダウンロードしてご参照ください。
※当記事ではnProbeのみを利用しております。なお、nProbeの評価版は25,000フローを受信した時点でフローの受信が停止しますのでご注意ください。

ドキュメント|ntopng – ジュピターテクノロジー株式会社 (jtc-i.co.jp)

前提条件

nProbeの導入モードについて

当記事では、nProbeを「コレクタモード」で導入し、Cisco社のCatalystスイッチからRSPANにより、nProbeへミラーパケットを送信しフローデータを生成しています。
高度な設定等が不要で、ミラーポート(SPAN)の設定のみで手軽にLAN内の通信を可視化することができます。
※Cisco社製スイッチ以外でもミラーポートに対応するスイッチであれば導入可能です。

また、生成したフローデータはMySQLやDiskへの保存のほか、JSON形式によりSYSLOGに転送することが可能です。

nProbeでは、コレクタモードの他にも、ProbeモードやProxyモードがあります。
各モードの詳細は以下をご参照ください。
Proxyモード、Probeモード、コレクタモード|nProbe – ジュピターテクノロジー株式会社 (jtc-i.co.jp)

nProbeの設定

以下のファイルを修正します。

/etc/nprobe/nprobe.conf

修正内容は以下の通りです。

通信を受信(フローを生成する)インターフェースの指定

「-i」オプションにて通信を受信するインターフェースを指定します。

~省略~
# -i|--interface
# Specifies the physical network interface that nProbe will use to perform the
# monitoring. On Unix you can specify the interface name (e.g. -i lo) whereas on Windows
# you must use the interface number instead (see -h to see the list of numeric ids).
# To disable monitoring from physical interfaces (e.g., when nProbe is used in
# collector-only mode) specify -i=none
#
# -i=none
# -i=eth1
#-i=lo
-i=ens160 # ← 通信を受信するインターフェース名に修正します。 
~省略~

SYSLOGへのフローデータ転送設定およびログフォーマット設定

末尾に以下の内容を追記します。

--json-to-syslog
-T="@NTOPNG@ %SRC_AS_MAP %DST_AS_MAP"

※「@NTOPNG@」形式とすることで、レイヤー7のプロトコル名やHTTPのURL、DNSクエリの内容等を出力することができます。これは市販のフローコレクタにはないnProbeならではの機能です。
また、当記事ではAS番号を元に割り出された組織名を出力する設定(%SRC_AS_MAP %DST_AS_MAP)を追加しています。

出力可能な項目についてはntop社のドキュメントをご参照ください。

Flow Information Elements — nProbe 9.3 documentation (ntop.org)

nProbeの再起動

以下のコマンドでnProbeを再起動します。

$ sudo systemctl restart nprobe

フローデータの出力確認

tail/less/more等のコマンドで以下のファイルを確認します。

/var/log/syslog

フローデータがJSON形式で出力されていれば設定は完了です。

Jun 29 10:02:39 ntop-demo [2764056]: {"56":"xx:xx:xx:xx:xx:xx","57":"xx:xx:xx:xx:xx:xx","10":0,"14":0,"58":999,"8":"192.168.xxx.xxx","12":"xxx.xxx.xxx.xxx","7":55378,"11":443,"27":"::","28":"::","60":4,"4":6,"35632.57590":"91","1":250,"2":2,"23":80,"24":2,"22":1624960927,"21":1624960927,"35632.57550":24,"35632.57551":16,"35632.57981":0,"35632.57595":0.000,"35632.57596":0.000,"35632.57597":0.000,"35632.57888":258,"35632.57892":1024,"35632.57583":0,"35632.57584":0,"35632.57581":1,"35632.57582":0,"35632.57552":0,"35632.57553":0,"35632.57677":"","35632.57679":"0","35632.57680":"0","35632.57652":"","35632.57833":"137.116.157.26","35632.57832":"","35632.57653":"0","35632.57660":"","35632.57661":"","5":2,"55":0,"35632.57915":"","35632.57916":"Microsoft Corporation","34":1,"42":4680}

rsyslogによる外部SYSLOGサーバへの転送設定

これまでの設定でインターフェースで受信したパケットからフローを生成し、OS上のSYSLOGに転送することができました。
外部のSYSLOGサーバへ転送する場合は、以下の設定を行います。

「/etc/rsyslog.d」の下に新しいファイルを作成します。

$ sudo vi /etc/rsyslog.d/99-flow.conf

設定例は以下の通りです。
※単純に”{}”で囲まれたログがあった場合に転送する設定としています。

:msg, regex, "\{.*\}"   @192.168.x.x #←外部SYSLOGサーバのIPアドレス

※”@”の場合はUDP、”@@”の場合はTCPでの転送となります。

設定後rsyslogを再起動し設定を再読み込みします。

$ sudo systemctl restart rsyslog

LogStare Collectorでの収集

上記で設定したSYSLOGは当社LogStare Collectorでも受信することが可能です。
以下の記事をご参照ください。

  • syslogにて転送されたメッセージは「SYSLOG収集」にてLSCで受信します。「SYSLOG収集」につきましては、以下の記事をご参照ください。
    SYSLOG収集
  • 「SYSLOG収集」にて利用されるポート番号はデフォルトでtcp/udp共に514となっています。環境設定より「SYSLOG収集」にて利用されるポート番号を変更することで514以外のポートで「SYSLOG収集」が可能となります。環境設定につきましては、以下の記事をご参照ください。
    LogStare Collector における環境設定について

LogStare Reporter / LogStare Quintでのレポート例

当社のLogStare ReporterおよびLogStare QuintはnProbeが出力するフローデータの可視化に対応しています。
※当記事で紹介したJSON形式のデータを対象としています。

以下はレポートの一例です。

L7プロトコル別の集計

nProbeが識別したレイヤー7プロトコル名別に、フロー件数(表示上はログ件数)と合計通信量で集計したレポートです。
想定していないアプリケーションが異常なトラフィックを発生させていないか確認することができます。
※L7プロトコル名は、ログに記録されたプロトコルIDを当社製品の機能により置換して表示しています。
プロトコルIDの一覧は以下のサイトで確認できます。
nDPI/ndpi_protocol_ids.h at abd6bce6f9f046797ab897330605cb69e76ca953 · ntop/nDPI · GitHub

LogStare Reporter / Quintでは、表示された項目からさらに送信元IPアドレスや宛先IPアドレスなどをクローズアップして分析することが可能です。

送信元IPアドレス別の通信先数集計

送信元IPアドレス別に、ユニークな宛先IPアドレス数を集計したレポートです。
想定外の端末が多数のホストと通信していないか確認することができます。

LogStare Reporter / Quintでは、表示された項目からさらにポート番号やレイヤー7プロトコルなどをクローズアップして分析することが可能です。

HTTPメソッド別の集計

HTTPのメソッド別に、通信量を集計したレポートです。(SSL/TLS通信を除く)
POSTされたデータの多い端末などをクローズアップして調べることが可能です。

LogStare Reporter / Quintでは、表示された項目からさらにURLや送信元IPアドレスなどをクローズアップして分析することが可能です。

PDFレポート

最後に、これらのレポートは、日次、週次、月次でメールによるPDF配信も可能です。


※レポートイメージ

nProbeを使えば、ファイアウォール等では収集の難しい内部サーバ間の通信やクラウド上のIaaSサーバ上に流れる通信など、企業内のあらゆる通信を可視化することが可能となります。
特にLAN内部の通信を可視化、分析することで、内部不正やマルウェアの水平感染などの兆候をつかめる可能性もありますので、ぜひご活用いただけますと幸いです。

■nProbeに関するお問い合わせ
ジュピターテクノロジー株式会社様お問い合わせフォーム
お問い合わせ一覧 – ジュピターテクノロジー株式会社 (jtc-i.co.jp)

■LogStare製品に関するお問い合わせ
当社お問い合わせフォーム
お問い合わせ | AI予測・システム監視・ログ管理を統合したセキュリティ・プラットフォーム LogStare(ログステア)

Nutanix Prism ElementにおけるSNMP監視/REST API監視について前のページ

SonicWall UTMにてSNMP(v1/v2/v3)を有効化する方法について次のページ

ピックアップ記事

  1. 自社製品をAMIにしてマーケットプレイスへ出品
  2. IoT機器「Raspberry pi」とLogStare Collectorで温…
  3. Zabbixヒストリデータのレポート生成について
  4. ログフォワーダー「okurun.jar」について

関連記事

  1. Tech-Blog

    Linuxにて特定のアウトバウンド通信を許可するための設定例

    当記事では、Linuxにて特定のアウトバウンド通信を許可するための設定…

  2. NW機器

    ネットワーク機器への不正接続の検知(PaloAlto)

    ネットワーク機器の空きポートに機器が接続された場合に、管理者へメールを…

  3. Windows/Linux

    Windows Server 2016 (2019,2012) /Windows 10 にて、監査ロ…

    当記事では、WMI における各種監査ログを出力するまでの設定方法を記載…

  4. Windows/Linux

    Windows Server (2019,2016, 2012 R2)にSNMP (v1, v2c)…

    当記事では、Windows Server にSNMP の設定を投入する…

  5. NW機器

    Nutanixを監視したいときのメトリクス監視項目例(API v2)

    当記事ではLogStare Collector(以下、LSC)でのNu…

  6. Windows/Linux

    Windows firewallログをLSCにて収集する方法

    当記事では、Windows firewallログをLogStare C…

secuavail

logstare collector

logstare collector

  1. NW機器

    SonicWall UTMにてSNMP(v1/v2/v3)を有効化する方法につい…
  2. NW機器

    SonicWall UTMにSyslog送信設定を追加する方法について
  3. ログ分析・監視テクニック

    nProbeであらゆる通信をログに記録し可視化する
  4. NW機器

    Nutanix Prism ElementにおけるSNMP監視/REST API…
PAGE TOP