Snort の検知ログを GCP BigQuery へ送ってみた

2021 年 9 月 30 日morikawa

プロダクトエンジニアリング部の morikawa です。Zabbix や Ansible の記事ばかり書いてましたが、最近ようやく GCP BigQuery なども触り始めたので今回は BigQuery 関連の記事にしてみました。

今回 BigQuery に送ったのは OSS の IDS/IPS ソフトウェアである Snort で検知したログになります。

要するに Snort インストールしてログを td-agent + fluent-plugin-bigquery で BigQuery に送っただけではあるんですが、ログフォーマットの解析であったり、BigQuery にバッチ読み込みでログを送る際にいろいろつまずいてドキュメントを漁って調べることも多かったので今回記事にした次第です。

Snort のインストール、BigQuery 側のアカウントやデータセットの準備、td-agent のインストールからその設定まで一通り記載してみたので、記事は長いですが再現は比較的容易かと思います。部分的に参照したい場合は以下の目次をご活用下さい。

Snort バージョンについて
Snort がインストールされる環境
Snort セットアップ
GCP BigQuery 側の設定
Snort サーバから td-agent を用いて GCP BigQuery へログを送付
GCP BigQuery でログを確認
まとめ

Snort バージョンについて

Snort はバージョン 2.9.18-1 を利用しています

Snort がインストールされる環境

Snort は CentOS7 のマシンにインストールを行います
Snort がインストールされるマシンの以下のネットワークインターフェースに入ってくるパケットを検査対象とします。このネットワークインターフェースはネットワーク機器側でミラーポート (他ポートへの通信をコピーしてパケットを送出するポート) に接続されているものとします
- eno49

Snort セットアップ

Snort インストール

今回は Snort は公式サイトの rpm パッケージを用います。(ファイル名に “centos8" が含まれていて CentOS8 向けのように見えますが CentOS7 でも動きました)

まず、パッケージのインストールに必要な daq パッケージ、また snortd を起動する際に必要とされる libdnet パッケージをインストールしておきます。

# yum --enablerepo=epel install daq libdnet

公式サイトから rpm パッケージをダウンロードします。

# cd /usr/local/src
# curl -O -L https://www.snort.org/downloads/snort/snort-2.9.18-1.centos8.x86_64.rpm

rpm コマンドでインストールします。

# rpm -ivh snort-2.9.18-1.centos8.x86_64.rpm

Snort ルールファイルの取得と展開

Snort はルールファイルを取得し、特定のディレクトリ上に展開する必要がありますが、ルールファイルを取得するにはまずユーザ登録が必要になります。

Snort – Network Intrusion Detection & Prevention Systemからユーザ登録を行います。

ユーザ登録後、 Snort Rules and IDS Software Download へアクセスし、インストールしたバージョン (今回は 2.9.18-1) に対応したルールファイル (今回の場合は snortrules-snapshot-29180.tar.gz ) をダウンロードします。

なお、ユーザ登録すると Oinkcode が発行され、公式サイトのアカウント画面で確認ができます。この Okincode を用いると、以下のようにルールファイルをコマンドラインで取得も可能になります。 Oinkcode はユーザごとに異なりますので、<Oinkcode> の箇所は置き換えてください。

$ wget https://www.snort.org/rules/snortrules-snapshot-29180.tar.gz?oinkcode=<Oinkcode> -O snortrules-snapshot-29180.tar.gz

ダウンロードした tar.gz ファイルは Snort をインストールしたサーバにコピーし、展開して /etc/snort/rules/ 以下にコピーします。以下が作業の例です。 (公式サイトにもやり方は記載されていますが、その通りだと手元では上手く動かなかったため、不正アクセス検知システムのSnort インストール | ex1-lab などを参考にルールファイル設置のやり方をカスタマイズしています)

# cd /usr/local/src
# wget https://www.snort.org/rules/snortrules-snapshot-29180.tar.gz?oinkcode=<Oinkcode> -O snortrules-snapshot-29180.tar.gz
# mkdir snortrules-snapshot-29180
# tar -xvzf snortrules-snapshot-29180.tar.gz -C snortrules-snapshot-29180
# chown -Rv root:root snortrules-snapshot-29180
# mv -v snortrules-snapshot-29180/rules/* /etc/snort/rules/
# mv -v snortrules-snapshot-29180/so_rules/ /etc/snort/
# mv -v snortrules-snapshot-29180/preproc_rules/ /etc/snort/
 
# ls -1d /etc/snort/*rules
/etc/snort/preproc_rules
/etc/snort/rules
/etc/snort/so_rules
 
# ls /etc/snort/*rules
/etc/snort/preproc_rules:
decoder.rules  preprocessor.rules  sensitive-data.rules
 
/etc/snort/rules:
VRT-License.txt              info.rules               protocol-voip.rules
app-detect.rules             local.rules              pua-adware.rules
                                     :             
 
/etc/snort/so_rules:
browser-chrome.rules   indicator-shellcode.rules  protocol-scada.rules
browser-ie.rules       malware-cnc.rules          protocol-snmp.rules
                                 :

ネットワークインターフェースの設定

検査対象のパケットを受け取る eno49 デバイスについて、IP アドレス無しで有効化できるよう BOOTPROTO を none に変更し、インターフェースを起動します。

# sed -i 's/^BOOTPROTO=.*$/BOOTPROTO=none/' /etc/sysconfig/network-scripts/ifcfg-eno49
 
# ifdown eno49 && ifup eno49

次に、他ホスト宛のパケットを受け取るためにプロミスキャストモードの設定も行います。ここでは、サービス起動時に自動的に有効化できるよう、rc.local に設定を記載してそれを反映させるという方法を採っています。

まず作業前に、該当のネットワークインターフェースがパケットを受け取っていないことを確認します。

# watch -n 1 -d "ip -s link show dev eno49"
 
6: eno49: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 80:30:e0:37:38:80 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    1370508694 3824414  0       0       0       9939                   ← 数値に変化がないことを確認
    TX: bytes  packets  errors  dropped carrier collsns
    4824       44       0       0       0       0

rc.local ファイルにプロミスキャストモードを有効にするコマンドを追加します。

# echo "/sbin/ip link set eno49 promisc on" >> /etc/rc.d/rc.local

rc.local が自動起動するよう、rc.local ファイルを実行可能にし、systemctl から自動起動の有効化と実際の起動を実施します。

# chmod -v u+x /etc/rc.d/rc.local
# systemctl enable rc-local
# systemctl start rc-local
 
# systemctl status rc-local
 
● rc-local.service - /etc/rc.d/rc.local Compatibility
   Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled)
   Active: active (exited) since 金 2021-08-27 16:48:10 JST; 5s ago
  Process: 16671 ExecStart=/etc/rc.d/rc.local start (code=exited, status=0/SUCCESS)
 
 8月 27 16:48:10 systemd[1]: Starting /etc/rc.d/rc.local Compatibility...
 8月 27 16:48:10 systemd[1]: Started /etc/rc.d/rc.local Compatibility.

rc.local サービス起動時にファイルに記載したプロミスキャストモード有効化コマンドが実行されているはずなので、これでパケットを受け取る状態になっているはずです。ネットワークインターフェースの状態を再確認してみます。

# watch -n 1 -d "ip -s link show dev eno49 "
 
6: eno49: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000    ← PROMISC の文字列の表示を確認
    link/ether 80:30:e0:37:38:80 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    1414908438 4026069  0       0       0       10607      ← RX 側の bytes, packets のカウントが上がることを確認
    TX: bytes  packets  errors  dropped carrier collsns
    4824       44       0       0       0       0

Snort 設定

snort.conf ファイルの編集

検査対象の IP アドレスの設定を行うため、/etc/snort/snort.conf を編集します。

# cd /etc/snort
# cp -avi snort.conf{,.org}
# vi snort.conf

ここで以下について修正を加えます。

HOME_NET
- ここに記載された IP アドレスへの通信についての検査を行います。
  - 以下に記載しているのは例になります。
- 管理しているシステムの IP アドレスをリストしておくことで、外向きの通信の検査が除外されるという効果も生じます。
EXTERNAL_NET
- 監視対象以外のネットワークを指定します。
WHITE_LIST_PATH, BLACK_LIST_PATH
- 以降で用意するホワイトリスト、ブラックリストファイルの置き場のパスを設定します
dynamicdetection
- 今回はこれは利用しないためコメントアウト

差分は以下のようになります。

# diff -ubr /etc/snort/snort.conf{.org,}
--- /etc/snort/snort.conf.org   2021-06-08 18:42:13.000000000 +0900
+++ /etc/snort/snort.conf       2021-08-27 12:34:43.788621435 +0900
@@ -42,10 +42,10 @@
 ###################################################
 
 # Setup the network addresses you are protecting
-ipvar HOME_NET any
+ipvar HOME_NET [192.0.2.0/24,198.51.100.0/24,203.0.113.0/24]
 
 # Set up the external network addresses. Leave as "any" in most situations
-ipvar EXTERNAL_NET any
+ipvar EXTERNAL_NET !$HOME_NET
 
 # List of DNS servers on your network
 ipvar DNS_SERVERS $HOME_NET
@@ -110,8 +110,8 @@
 # not relative to snort.conf like the above variables
 # This is completely inconsistent with how other vars work, BUG 89986
 # Set the absolute path appropriately
-var WHITE_LIST_PATH ../rules
-var BLACK_LIST_PATH ../rules
+var WHITE_LIST_PATH rules
+var BLACK_LIST_PATH rules
 
 ###################################################
 # Step #2: Configure the decoder.  For more information, see README.decode
@@ -250,7 +255,7 @@
 dynamicengine /usr/lib64/snort-2.9.18_dynamicengine/libsf_engine.so
 
 # path to dynamic rules libraries
-dynamicdetection directory /usr/local/lib/snort_dynamicrules
+#dynamicdetection directory /usr/local/lib/snort_dynamicrules
 
 ###################################################
 # Step #5: Configure preprocessors

ホワイトリスト、ブラックリスト作成

上記設定ファイルの以下の箇所で指定されるファイルが当初は存在しないため作成する必要があります。

# grep -E "(WHITE|BLACK)_LIST_PATH" /etc/snort/snort.conf
var WHITE_LIST_PATH rules
var BLACK_LIST_PATH rules
   whitelist $WHITE_LIST_PATH/white_list.rules, \
   blacklist $BLACK_LIST_PATH/black_list.rules

以下のように touch コマンドで空ファイルを作成します。

# touch /etc/snort/rules/white_list.rules
# touch /etc/snort/rules/black_list.rules

検査対象ネットワークインターフェースの設定、ログへのインターフェース名の記載

eno49デバイスを監視対象にするための設定を /etc/sysconfig/snort に記載します。また以下についても併せて設定しています。

ログへのインターフェース名の記載
- デフォルトではインターフェース名はログに記載されません。インターフェースが一つの場合は不要ですが、複数のインターフェースに対して検査する場合、違いに意味持たせるため、PRINT_INTERFACE を有効にするのをおすすめします。

# cd /etc/sysconfig/
# cp -avi snort{,.org}
# vi snort

編集結果の差分は以下のようになります。

# diff -ubr /etc/sysconfig/snort{.org,}
--- /etc/sysconfig/snort.org    2021-05-24 12:46:33.000000000 +0900
+++ /etc/sysconfig/snort        2021-08-26 10:22:18.626417073 +0900
@@ -12,7 +12,8 @@
 # What interface should snort listen on?  [Pick only 1 of the next 3!]
 # This is -i {interface} on the command line
 # This is the snort.conf config interface: {interface} directive
-INTERFACE=eth0
+#INTERFACE=eth0
+INTERFACE="eno49"
 #
 # The following two options are not directly supported on the command line
 # or in the conf file and assume the same Snort configuration for all
@@ -89,7 +90,8 @@
 # Print out the receiving interface name in alerts.
 # -I
 # config alert_with_interface_name
-PRINT_INTERFACE=0
+#PRINT_INTERFACE=0
+PRINT_INTERFACE=1
 
 # When dumping the stats, what log file should we look in
 SYSLOG=/var/log/messages

Snort 動作確認

Snort 起動

snort を起動します。

# /etc/init.d/snortd start
 
Starting snortd (via systemctl):                           [  OK  ]

messages ログを確認してエラーが出ていないかを確認してみましょう。Commencing packet processingといったメッセージが表示されていれば問題ない模様です。

# less /var/log/messages
 
Aug 26 10:28:39 ids1 systemd: Starting SYSV: snort is a lightweight network intrusion detection tool that currently detects more than 1100 host and network vulnerabilities, portscans, backdoors, and more....
Aug 26 10:28:39 ids1 snort[5761]: Running in IDS mode
Aug 26 10:28:39 ids1 snort[5761]:
Aug 26 10:28:39 ids1 snort[5761]:        --== Initializing Snort ==--
Aug 26 10:28:39 ids1 snort[5761]: Initializing Output Plugins!
Aug 26 10:28:39 ids1 snort[5761]: Initializing Preprocessors!
Aug 26 10:28:39 ids1 snort[5761]: Initializing Plug-ins!
Aug 26 10:28:39 ids1 snort[5761]: Parsing Rules file "/etc/snort/snort.conf"
Aug 26 10:28:39 ids1 snort[5761]: PortVar 'HTTP_PORTS' defined :
Aug 26 10:28:39 ids1 snort[5761]: [ 80:81 311 383 591 593 901 1220 1414 1741 1830 2301 2381 2809 3037 3128 3702 4343 4848 5250 6988 7000:7001 7144:7145 7510 7777 7779 8000 8008 8014 8028 8080 8085 8088 8090 8118 8123 8180:8181 8243 8280 8300 8800 8888 8899 9000 9060 9080 9090:9091 9443 9999 11371 34443:34444 41080 50002 55555 ]
                                   : 
Aug 26 10:28:50 ids1 snort[5777]: [ Port Based Pattern Matching Memory ]
Aug 26 10:28:50 ids1 snort[5777]: +- [ Aho-Corasick Summary ] -------------------------------------
Aug 26 10:28:50 ids1 snortd: [  OK  ]#015Spawning daemon child...
Aug 26 10:28:50 ids1 snortd: My daemon child 5793 lives...
Aug 26 10:28:50 ids1 snortd: Daemon parent exiting (0)
Aug 26 10:28:50 ids1 snort[5777]: | Storage Format    : Full-Q
Aug 26 10:28:50 ids1 snort[5777]: | Finite Automaton  : DFA
Aug 26 10:28:50 ids1 snort[5777]: | Alphabet Size     : 256 Chars
Aug 26 10:28:50 ids1 snort[5777]: | Sizeof State      : Variable (1,2,4 bytes)
Aug 26 10:28:50 ids1 snort[5777]: | Instances         : 203
Aug 26 10:28:50 ids1 snort[5777]: |     1 byte states : 190
Aug 26 10:28:50 ids1 snort[5777]: |     2 byte states : 12
Aug 26 10:28:50 ids1 snort[5777]: |     4 byte states : 1
Aug 26 10:28:50 ids1 snort[5777]: | Characters        : 203633
Aug 26 10:28:50 ids1 snort[5777]: | States            : 161579
Aug 26 10:28:50 ids1 snort[5777]: | Transitions       : 28915351
Aug 26 10:28:50 ids1 snort[5777]: | State Density     : 69.9%
Aug 26 10:28:50 ids1 snort[5777]: | Patterns          : 9680
Aug 26 10:28:50 ids1 snort[5777]: | Match States      : 9972
Aug 26 10:28:50 ids1 snort[5777]: | Memory (MB)       : 116.05
Aug 26 10:28:50 ids1 snort[5777]: |   Patterns        : 1.13
Aug 26 10:28:50 ids1 snort[5777]: |   Match Lists     : 2.55
Aug 26 10:28:50 ids1 snort[5777]: |   DFA
Aug 26 10:28:50 ids1 snort[5777]: |     1 byte states : 1.06
Aug 26 10:28:50 ids1 snort[5777]: |     2 byte states : 45.85
Aug 26 10:28:50 ids1 snort[5777]: |     4 byte states : 65.13
Aug 26 10:28:50 ids1 snort[5777]: +----------------------------------------------------------------
Aug 26 10:28:50 ids1 snort[5777]: [ Number of patterns truncated to 20 bytes: 553 ]
Aug 26 10:28:50 ids1 snort[5777]: pcap DAQ configured to passive.
                                   : 
Aug 26 10:28:50 ids1 snort[5793]:        --== Initialization Complete ==--
Aug 26 10:28:50 ids1 snort[5793]:
Aug 26 10:28:50 ids1 snort[5793]:   ,,_     -*> Snort! <*-
Aug 26 10:28:50 ids1 snort[5793]:  o"  )~   Version 2.9.18 GRE (Build 169)
Aug 26 10:28:50 ids1 snort[5793]:   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/contact#team
Aug 26 10:28:50 ids1 snort[5793]:           Copyright (C) 2014-2021 Cisco and/or its affiliates. All rights reserved.
Aug 26 10:28:50 ids1 snort[5793]:           Copyright (C) 1998-2013 Sourcefire, Inc., et al.
Aug 26 10:28:50 ids1 snort[5793]:           Using libpcap version 1.5.3
Aug 26 10:28:50 ids1 snort[5793]:           Using PCRE version: 8.32 2012-11-30
Aug 26 10:28:50 ids1 snort[5793]:           Using ZLIB version: 1.2.7
Aug 26 10:28:50 ids1 snort[5793]:
Aug 26 10:28:50 ids1 snort[5793]:           Rules Engine: SF_SNORT_DETECTION_ENGINE  Version 3.2  <Build 1>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_SMTP  Version 1.1  <Build 9>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_SIP  Version 1.1  <Build 1>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_SDF  Version 1.1  <Build 1>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_S7COMMPLUS  Version 1.0  <Build 1>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_REPUTATION  Version 1.1  <Build 1>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_POP  Version 1.0  <Build 1>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_SSLPP  Version 1.1  <Build 4>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_MODBUS  Version 1.1  <Build 1>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_IMAP  Version 1.0  <Build 1>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_GTP  Version 1.1  <Build 1>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_SSH  Version 1.1  <Build 3>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_FTPTELNET  Version 1.2  <Build 13>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_DNS  Version 1.1  <Build 4>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_DNP3  Version 1.1  <Build 1>
Aug 26 10:28:50 ids1 snort[5793]:           Preprocessor Object: SF_DCERPC2  Version 1.0  <Build 3>
Aug 26 10:28:50 ids1 snort[5793]: Commencing packet processing (pid=5793)

脆弱性検出の確認

snort が起動した状態でしばらく待ち、その後検知ログを確認します。ネットワークの状況によりけりですが、インターネットからのアクセスを受け付ける状況であれば何かしらの通信は検知されることになるかと思います。

# cat /var/log/snort/eno49/alert
08/26-12:36:00.235300  [**] [1:44687:3]  <eno49> SERVER-WEBAPP Netgear DGN1000 series routers authentication bypass attempt [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 198.51.100.32:1085 -> 203.0.113.89:80
08/26-12:45:27.327795  [**] [1:46624:2]  <eno49> SERVER-WEBAPP GPON Router authentication bypass and command injection attempt [**] [Classification: Web Application Attack] [Priority: 1] {TCP} 198.51.100.156:4006 -> 203.0.113.202:80
                      :

GCP BigQuery 側の設定

GCP BigQuery 側の設定を行います。Google のアカウント自体はすでに存在し、利用料の支払いの準備も整っていることを前提にしています。

プロジェクトの作成

既に適切なプロジェクトの用意があれば不要ですが、ない場合にはプロジェクトの作成から始めます。

https://console.cloud.google.com/ へアクセス
画面上部の「プロジェクトの選択」をクリックし、そこで表示されるウィザードで「新しいプロジェクト」をクリック
以下入力後に「作成」をクリックしてプロジェクトを作成
- プロジェクト名に入力した文字列は原則的にはそれをつなぎ併せてプロジェクト IDになるようです。既にIDとして使われている名称と重複した場合は数値 (おそらく内部的にIDとして使用されるもの) が自動で付与されるようです。プロダクトIDにランダムっぽい数値が含まれるのが嫌であれば既存のものと重複しないようなある程度長い名称をプロジェクト名に指定したほうが良いようです。後で変更はできないので、長く使うのであれば慎重に決めましょう。

一般的にはプロジェクト作成後には IAM にユーザ登録するなどの対応が必要ですがここでは最低限必要なものに絞って記載します。

データセット、ロール、サービスアカウント、JSON 鍵の準備

外部から BigQuery にログを送る場合、データを格納する器となるデータセットとそこへのアクセス権をもつ認証キーが最低限必要となります。今回認証キーの形式は JSON にします。

この JSON 鍵を強い権限を持つアカウントで発行してしまえばログの受付はできますが、ログを送付するシステム側に不要な権限も与えることになるため、今回は特定のデータセットに対してテーブルの作成、ログのインポートを行うだけの必要最低限の権限を付与したサービスアカウントを用意し、 JSON 鍵を発行してみます。

データセットを作成

https://console.cloud.google.com/bigquery へアクセス
プロジェクトを上記で作成したものへと変更
画面右側の「データセットを作成」をクリック
データセット作成画面で以下を入力して「データセットを作成」をクリック
- データセット ID (英数字とアンダースコアのみ使用可能): snort
- データのロケーション: 東京 (asia-northeast1)
  - デフォルトは US 設定になっており、明示的に設定しないとログはアメリカに送られます。
    - AWS のようにデフォルトロケーションを東京リージョンにするといったことはできない模様です。
    - 日本国内ロケーションとしては他に大阪 (asia-northeast2) もあります。
- デフォルトのテーブルの有効期限: 366日
  - ここはお好み、ないしはログの保存ポリシー次第になります。有効期限は設定しないこともできますので IDS のログを永続的に保存したいのであれば有効期限を設定しないのが良いです。この記事では 1 年後に削除する設定を入れてみています。
- 暗号化: Google が管理する鍵

BigQuery データ挿入者 (カスタムロール) の作成

https://console.cloud.google.com/ ヘアクセス
メニュー「IAM と管理」→「ロール」を選択
「＋ロールを作成」をクリック
ロール作成画面で以下を入力
- タイトル: BigQuery データ挿入者 (カスタムロール)
- 説明: 外部システムからのデータのインポートに利用することを想定したロール。インポートの際はテーブル作成も行うことを前提としている。
- ロールのリリース段階: 一般提供
- 権限
  - 以下の 6 つの権限を付与
    - bigquery.datasets.get
    - bigquery.tables.create
    - bigquery.tables.get
    - bigquery.tables.list
    - bigquery.tables.update
    - bigquery.tables.updateData
  - 設定に関する補足
    - 権限の数が数千以上と半端なく多く、普通に選択しようとしていると辛いので、「＋権限を追加」をクリック後「ロールで権限をフィルタリングする」で以下の既存ロールを選択すると上記 6 つの権限を含んだ 30 個程度の権限に絞られるため楽です
      - BigQuery データ編集者
- 最後に「作成」をクリック

サービスアカウントの作成

サービスアカウント自体にもロールをセットする機能はありますが、試したところデータセット毎に権限設定することができなかったため、ここでは行わずデータセットと紐付けるタイミングでロールを関連付けます。

https://console.cloud.google.com/ ヘアクセス
メニュー「IAM と管理」→「サービスアカウント」を選択
「＋サービスアカウントの作成」をクリック
サービスアカウント作成ウィザードで以下を入力
- サービスアカウントの詳細
  - サービスアカウント名: IDS Snort Alerts Importer
  - サービスアカウントの説明: IDS (Snort利用) のアラートデータのインポートに利用。このサービスアカウントのキーは IDS サーバで使用される。
- このサービスアカウントにプロジェクトに対してのジョブ設定を許可する
  - ロール: BigQuery ジョブユーザー
- ユーザーにこのサービスアカウントへのアクセスを許可
  - 設定しません
「完了」をクリック

データセットに対して個別にサービスアカウントに権限付与

https://console.cloud.google.com/ ヘアクセス
メニュー「IAM と管理」→「サービスアカウント」を選択
上記で作成したサービスアカウントについてメールアドレスが「メール」の欄に記載されているのでそれをコピーしておく
https://console.cloud.google.com/bigquery ヘアクセス
エクスプローラ内のプロジェクト、データセット選択画面で上記で作成したデータセットを選択し、→ snort を選択
右側の人のようなアイコンであるところの「共有データセット」をクリック
データセットの権限画面で「メンバーを追加」の欄に上記メールアドレスをペースト
「ロールを選択」のプルダウンはカスタム → BigQuery データ挿入者 (カスタムロール) を選択
「追加」をクリック
最後に下部の「完了」をクリック

なお、既存設定を確認したい場合は先程と同様に「データセットの権限」画面へ移動すると、「BigQuery データ挿入者 (カスタムロール)（1 人のメンバー）」が確認できる。内容はプルダウンで確認が可能となっています。

鍵の発行

https://console.cloud.google.com/ ヘアクセス
メニュー「API とサービス」→「認証情報」を選択
「サービスアカウント」欄から上記で作成した IDS Snort Alerts Importer を選択
「キー」欄で「鍵を追加」をクリックし「新しい鍵を作成」をクリック
キーのタイプとしては JSON を選択して「作成」をクリック
鍵となる JSON ファイルがダウンロードされるので一旦ローカルPC上に保存

このJSONファイルは権限が対象のデータセット上でのテーブル作成とログ送付に権限は絞られてはいますが機密な情報になるので、以降の作業でサーバ上に保存したら手元からは削除しましょう

以上で GCP 上での準備は完了です。

Snort サーバから td-agent を用いて GCP BigQuery へログを送付

td-agent と fluent-plugin-bigquery などのプラグインのインストール

Snort サーバに td-agent バージョン 4 をインストールします。バージョン 4 としているのは fluent-plugin-bigquery プラグインのためです。なお、仮に既に td-agent バージョン 3 以下がインストールされていてバージョン 4 に入れ替えるのが難しい場合はバージョン 4 をインストールしたログ中継サーバを用意するなどすると良いでしょう。

# curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent4.sh | sh

# td-agent-gem install fluent-plugin-record-reformer
# td-agent-gem install fluent-plugin-bigquery

fluent-plugin-bigquery プラグインでログを BigQuery にインポートする場合以下の 2 つの方法を採ることができます。

bigquery_load プラグインを使用
- 設定した間隔でログをバッチ処理でインポートします
- メリット
  - この方法で BigQuery にログをインポートする場合、インポート自体には費用がかかりません
- デメリット
  - 設定した間隔でログが送られるため、出力されるログを BigQuery で確認できるようになるまで時間がかかります
    - 後述の理由からあまり短い間隔を設定することもできません
  - 1 日のテーブルあたりの読み込みジョブの件数は 1,000 件まで、1 日のプロジェクトあたりの読み込みジョブは 50,000 件に制限されています
    - Fluentd と BigQuery を使用したリアルタイムのログ分析 | Cloud アーキテクチャセンター
    - ここでの「読み込むジョブの件数」はbigquery_load プラグインでインポートする回数に相当します
bigquery_insert プラグインを使用
- ログを BigQuery に対してストリーミング入力します。
- メリット
  - ログは数秒以内に BigQuery にインポートされるため、ほぼリアルタイムでログを BigQuery で確認することが可能です。
- デメリット
  - ストリーミング入力自体に費用がかかります。
    - 料金 | BigQuery: クラウドデータウェアハウス | Google Cloud

今回は bigquery_load プラグインで 10 分おきにログを送る例を示します。

td-agent の設定

バックアップを取って td-agent.conf を編集します。

$ su -
# cd /etc/td-agent
# cp -avi td-agent.conf{,.org.$(date +%Y%m%d)~}
# vi td-agent.conf

Output descriptions に以下の設定を追記します。

# Snort ログの時刻のフォーマットを %m/%d-%H:%M:%S から GCP BQ の TIMESTAMP 型として受け入れられる ISO 8601 (%Y-%m-%dT%H%M%S+09:00) 形式に変換
<filter snort.alert>
  @type record_transformer
  enable_ruby true
  auto_typecast true
  <record>
    time ${require 'time'; Time.parse(record["time"].to_s).iso8601.to_s}
  </record>
</filter>
 
# ログデータを GCP BQ が受け入れられる JSON 形式に変換
<match snort.alert>
  @type record_reformer
  renew_record false
  enable_ruby true
 
  tag ${tag}.reformed
  <record>
    fluent_raw_record ${record.to_json}
  </record>
</match>
 
<match snort.alert.reformed>
  @type bigquery_load
 
  # テーブル名に時刻情報を付与するために必要な設定
  # flush_interval はバッチジョブ読み込みの周期が秒で設定されている。テーブルあたり一日 1,000 回までの制限があるため注意 (https://cloud.google.com/bigquery/quotas?hl=ja#load_jobs)
  # path はログ出力されたデータが GCP に送られるまで一時的に保管されるパスで、"*" 部分には (おそらく他と重複が起こりにくいよう) ランダムな文字列がシステムから付与される
  <buffer time>
    @type file
    timekey      1d
    flush_interval 600
    path /var/log/td-agent/buffer/bigquery.snort.alert.*
  </buffer>
 
  auth_method json_key
  json_key /etc/td-agent/bq_json_key/snort-alert-importer.json
  location asia-northeast1
  project ids-snort-alert
  dataset snort
  table %Y-%m-%d
  auto_create_table true
  ignore_unknown_values true
  schema_path /etc/td-agent/bq_snort_alert_schema.json
</match>

Source descriptions に以下の設定を追記します。 expression 部分の正規表現は Fluentular: a Fluentd regular expression editor を利用するなどして作りました。

<source>
  @type tail
  @id snort_alert_tail
 
  # expression は Snort のログを構文解析するための正規表現
  <parse>
    @type regexp
    expression /^(?<time>[^ \.]*).\d*  \[\*\*\] \[(?<gid>\d*):(?<sid>\d*):(?<rev>\d*)\]  \<(?<device>[^ ]*)\> (?<msg>[^\[\]]*) \[\*\*\] \[Classification: (?<classtype>[^\]]*)\] \[Priority: (?<priority>\d*)\] {(?<proto>[^{} ]*)} (?<src>[\d\.]*):(?<srcport>\d*) -> (?<dst>[\d\.]*):(?<dstport>\d*)$/
    time_key time
    time_type string
    time_format %m/%d-%H:%M:%S
    keep_time_key true
    types gid:integer
    types sid:integer
    types rev:integer
    types priority:integer
    types srcport:integer
    types dstport:integer
  </parse>
 
  path /var/log/snort/*/alert
  pos_file /var/log/td-agent/snort.alert.pos
  tag snort.alert
</source>

JSON キーファイル作成

# install -m 0700 -o td-agent -g td-agent -d /etc/td-agent/bq_json_key
# touch /etc/td-agent/bq_json_key/snort-alert-importer.json
# chmod 0600 /etc/td-agent/bq_json_key/snort-alert-importer.json
# chown td-agent:td-agent /etc/td-agent/bq_json_key/snort-alert-importer.json
# vi /etc/td-agent/bq_json_key/snort-alert-importer.json
  
(発行した JSON キーの内容を書き込む)

スキーマファイル作成

# vi /etc/td-agent/bq_snort_alert_schema.json

[
    {"name": "time",         "type": "TIMESTAMP", "mode": "REQUIRED"},
    {"name": "gid",          "type": "INTEGER",   "mode": "NULLABLE"},
    {"name": "sid",          "type": "INTEGER",   "mode": "REQUIRED"},
    {"name": "rev",          "type": "INTEGER",   "mode": "NULLABLE"},
    {"name": "device",       "type": "STRING",    "mode": "NULLABLE"},
    {"name": "msg",          "type": "STRING",    "mode": "NULLABLE"},
    {"name": "classtype",    "type": "STRING",    "mode": "NULLABLE"},
    {"name": "priority",     "type": "INTEGER",   "mode": "REQUIRED"},
    {"name": "proto",        "type": "STRING",    "mode": "NULLABLE"},
    {"name": "src",          "type": "STRING",    "mode": "NULLABLE"},
    {"name": "srcport",      "type": "INTEGER",   "mode": "NULLABLE"},
    {"name": "dst",          "type": "STRING",    "mode": "NULLABLE"},
    {"name": "dstport",      "type": "INTEGER",   "mode": "NULLABLE"}
]

td-agent サービスを起動

# systemctl start td-agent

なお、個人的には td-agent の経験不足もあるとは思いますがだいたい何かエラーが出ます。上手く起動しない場合はすぐログを確認しましょう。

# less /var/log/td-agent/td-agent.log

td-agent 起動後のエラーでハマったもの

時刻の形式は GCP の TIMESTAMP 型で解釈できる形式に明示的に変更が必要

Snort の日時形式は少々独特で %m/%d-%H:%M:%S というスタイルであるため、これを GCP BigQuery に送る場合に明示的に変更する必要がありました。変更せずに送ろうとすると以下のエラーが…。

#0 job.load API (rows) ..  dataset="snort" table="2021-08-30" message="Error while reading data, error message: JSON parsing error in row starting at position 692: Couldn't convert value to timestamp: Could not parse '08/30-00:08:46' as a timestamp. Required format is YYYY-MM-DD HH:MM[:SS[.SSSSSS]] or YYYY/MM/DD HH:MM[:SS[.SSSSSS]] Field: time; Value: 08/30-00:08:46" reason="invalid"

なお、GCP BigQuery の TIMESTAMP 型として受け入れられる時刻形式は公式ドキュメント Cloud Storage からの CSV データの読み込み | BigQuery | Google Cloud に例として記載されています。

一般的な時刻の形式
- 2018-08-19 12:11
- 2018-08-19 12:11:35
- 2018-08-19 12:11:35.22
- 2018/08/19 12:11
- 2018-07-05 12:54:00 UTC
- 2018-08-19 07:11:35.220 -05:00
- 2018-08-19T12:11:35.220Z
Unix エポック時間
- 1534680695
- 1.534680695e11

私の場合は record_transformer の中で ruby の時刻関係の関数を呼び出して変換を行って対処しました。td-agent.conf 内の以下の部分になります。

# Snort ログの時刻のフォーマットを %m/%d-%H:%M:%S から GCP BQ の TIMESTAMP 型として受け入れられる ISO 8601 (%Y-%m-%dT%H%M%S+09:00) 形式に変換
<filter snort.alert>
  @type record_transformer
  enable_ruby true
  auto_typecast true
  <record>
    time ${require 'time'; Time.parse(record["time"].to_s).iso8601.to_s}
  </record>
</filter>

GCP BigQuery に入れるログは JSON 形式になっている必要がある

たまたま以前に BigQuery にインポートしたログが JSON 形式のものだったので意識していなかったのですが、JSON 形式にせずに BigQuery に送ろうとすると、JSON 形式を前提とする先方からエラーを返されます。何かしらのデータ構造になってるんだし問題ないでしょうという思い込みからしばしハマりました。

#0 job.load API (rows) ..  dataset="snort" table="2021-08-28" message="Error while reading data, error message: JSON table encountered too many errors, giving up. Rows: 1; errors: 1. Please look into the errors[] collection for more details." reason="invalid"

こちらは以下のように record_reformer の中で to_json 関数を使って変換することで対処しました。

# ログデータを GCP BQ が受け入れられる JSON 形式に変換
<match snort.alert>
  @type record_reformer
  renew_record false
  enable_ruby true
 
  tag ${tag}.reformed
  <record>
    fluent_raw_record ${record.to_json}
  </record>
</match>

bigquery_load プラグイン使用時は buffer セクションに path が必須

個人的には bigquery_insert プラグインを先に触っていたので、buffer セクション内の path の記載をサボってエラーに遭遇しました。

config error file="/etc/td-agent/td-agent.conf" error_class=Fluent::ConfigError error="buffer path is not configured. specify 'path' in <buffer>"

bigquery_load の buffer セクション内の path は、出力されたログを td-agent が読み込み、これを BigQuery に送り出すまでに溜めておくためのファイルのパスを示しているものです。当初この理解が及んでおらず、またウェブサイトを漁ると path に “*" (アスタリスク) がつく例が多く、「これ、読み込む先のファイル？」と誤解して混乱してしまったのですが、アスタリスクには (おそらく他と重複が起こりにくいよう) ランダムな文字列がシステムから付与されているようでした。ログを更新しつつ、該当のパスを watch コマンドでウォッチしてみると、ファイル生成→サイズ増加→ファイル消滅 (ログが BigQuery に送られた瞬間) → ファイル再度生成、が繰り返されるのが見て取れます。

  <buffer time>
    @type file
    timekey      1d
    flush_interval 600
    path /var/log/td-agent/buffer/bigquery.snort.alert.*
  </buffer>

以上で一通りやることは完了になります。

GCP BigQuery でログを確認

td-agent がエラーを吐かずに動作していれば BigQuery のログ転送は成功しているとみなして問題ないかと思います (私はそこからハマったりはしませんでした)。BigQuery のコンソールを開き、対象のデータセットを見てみると、 YYYY-MM-DD 形式のテーブルが作成され、その中にログが格納されていることが確認できるかと思います。

まとめ

今回は Snort のログを BigQuery に送るという一言で言えばそれだけの内容について、Snort のインストールから地道に書き出してみました、みたいな記事にしてみました。

Snort のインストールは調べてみるとソースからコンパイルというものが多かったですが、パッケージが意外とあっさり使えたのでそんなに苦労しませんでした。

やはり GCP BigQuery にログを送るというのが簡単なようで細かいところでつまずくところが多かったです。GCP も td-agent やそのプラグインも公式ドキュメントはもちろん充実してるんですが、よく分からないまま組み合わせて使おうとしてハマるということをまだ繰り返しております。イマドキですとシステムのログは BigQuery などの外部の分析基盤に転送していつでも解析できるみたいなのが標準になりつつあるようですし、もう少しサクサクと使いこなせるようになってトライコーンのシステムのログ周りの環境もアップデートしたいですね。

2021 年 9 月 30 日morikawa

Posted by morikawa