この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Norikraとは
Norikraとはリアルタイム集計プロダクトです。イベントストリームに対してSQLライクな言語で処理を書くことが出来ます。
例えば、ApacheのアクセスログをNorikraに流し込み、1分あたりのアクセス数やレスポンスタイムの最大値をリアルタイムに集計することが出来ます。
Norikraの利用例は作者であるtagomorisさんのブログで紹介があります。
今回は、Norikraを使ってDoS攻撃をブロックする仕組みを作ってみました。
DoS攻撃ブロックの仕組み
アクセス元はApacheのアクセスログから取得し、ログの受け渡しにはFluentdを利用しました。
ブロックの手順は以下のようになります。
- アクセスログをFluentdのin_tailプラグインで取得。
- Fluentdのout_norikraプラグインで、アクセスログをNorikraに流し込み。
-
Norikraのクエリで、単位時間あたりのアクセス数が多いIPアドレスを抽出。
結果をin_norikraプラグインでFluentdに出力。 -
IPアドレスのリストをout_exec_filterプラグインで、独自スクリプトに渡す。
独自スクリプト内の処理で、AWSのNetwork ACLの設定を変更し、問題のIPアドレスからのinboundを拒否する。
ブロック結果はそのまま、Fluentdに戻される。 -
out_snsプラグインで、ブロック結果をSNSのトピックに出力。
トピックのサブスクライバであるメールアドレス等に通知が飛ぶ。
上図の③にあるSQL風のクエリに注目してください。
重要なのはFROM句にある「m分ごと」の部分で、ここで指定した期間のログに対してクエリを実行することが出来ます。
これを使って、例えば「１分間で1000回以上アクセスのあるIPアドレス」といった抽出が可能になります。
では、実際に構築していきます。
前提
VPC内のEC2上に構築していきます。
AWSリソースへのアクセスが必要なので、IAM Role付きで立ち上げてください。
| AMI | Amazon Linux AMI 2014.03 |
| セキュリティグループ | 22/TCP, 80/TCP, 26578/TCPを許可 |
| IAM Role | Power User Access |
作業は基本的にec2-userで行います。
Norikraのインストール
NorikraはJRubyで動いているので、まずJrubyをインストールします。 *1
まず、rbenvをインストールし、
$ sudo yum install -y git gcc-c++
$ git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
$ exec $SHELL -l
$ rbenv --version
rbenv 0.4.0-95-gf71e227バージョンが確認できたら、JRubyをインストールします。
$ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
$ rbenv install -l|grep jruby
jruby-1.5.6
(snip)
jruby-1.7.9
jruby-9000-dev
jruby-9000+graal-dev
$ rbenv install jruby-1.7.9
$ rbenv shell jruby-1.7.9
$ ruby -v
jruby 1.7.9 (1.9.3p392) 2013-12-06 87b108a on OpenJDK 64-Bit Server VM 1.7.0_51-mockbuild_2014_03_13_04_35-b00 [linux-amd64]現時点の最新版、1.7.9をインストールしました。
普段使うRubyがJRubyになってしまうと辛いので、rbenv shellでログインシェルのみJRubyを利用するようにしています。
GemでNorikraをインストールします。
$ gem install norikra --no-ri --no-rdoc
$ rbenv rehash
$ which norikra
~/.rbenv/shims/norikra
$ gem list --local | grep norikra
norikra (0.1.5 java)
norikra-client-jruby (0.1.5 java)Norikraがインストールできました。
Norikraの起動と動作確認
起動する前に、ログや設定ファイルを設置するディレクトリを作成します。
$ sudo mkdir /{etc,var/log,var/run}/norikra
$ sudo chown ec2-user:ec2-user /{etc,var/log,var/run}/norikra/起動時に設定できるパラメータはいろいろあるのですが、とりあえず最低限のパラメータで起動してみましょう。
$ norikra start --stats=/etc/norikra/norikra.json -l /var/log/norikra --daemonizeパラメータの詳しい説明は公式ドキュメントを参照してください。
起動が確認できたら、NorikraのウェブUIにアクセスしてみましょう。
http://hostname:26578/
でアクセスできます。
Norikraが利用するメモリや、現在受付中のターゲット、設定済みのクエリ、処理されたイベント数が確認できます。
クエリの設定もこのUIから出来ます。
ウェブUIへのアクセスが確認できたところで、早速ターゲットを作ってみましょう。
ターゲットとはRDBで言うところのテーブルのようなものです。
$ norikra-client target open testこれで、「test」という名前のターゲットが作られました。
ウェブUIで確認してみましょう。
「Fields」項目が「lazy target」となっています。フィールドとはRDBで言うところのカラムのようなものです。ターゲット作成時にフィールドタイプを指定することも出来ますが、指定しなくても、イベント登録時に自動で判別してくれます。
では、testターゲットにイベントを流してみましょう。
$ echo '{"name":"spike", "age":27}' | norikra-client event send testウェブUIで確認すると、フィールドタイプが確定したことが確認できます。
ただ、クエリを登録していないため、いま流したイベントは処理されることなく流れてしまってます。
ウェブUIからクエリを登録してみましょう。
最初なので、全イベントを取得するクエリを「get_all」という名前で登録してみます。
「SELECT フィールド名 FROM ターゲット名」と、SQLと同じようにかけます。
フィールド名にはワイルドカードも使えます。
クエリを登録した状態で、イベントを流してみましょう。
$ echo '{"name":"jet", "age":36}' | norikra-client event send test
$ echo '{"name":"faye", "age":77}' | norikra-client event send testウェブUIで確認すると、今度はイベントがget_allクエリで処理されたことが確認できます。
最初に流したイベントが出力されていないことに注意してください。
Norikraはデータベースではないため、受け取ったイベントを保存することはありません。
クエリに当てはまるイベントが処理され、その処理結果が出力されます。
Norikraクライアントで結果を取得しましょう。
$ norikra-client event fetch get_all
{"time":"2014/03/31 05:40:58","name":"jet","age":36}
{"time":"2014/03/31 05:44:09","name":"faye","age":77}Norikraクライアントの使い方は公式ドキュメントを参照してください。
続いて、FluentdからNorikraにイベントを流すようにしましょう。
Fluentdのインストールと設定
Fluentdの前に、ログを出力するApacheをインストール、設定しておきます。
$ sudo yum install -y httpd24
$ echo ok | sudo tee /var/www/html/index.html
$ sudo service httpd start
$ sudo chkconfig httpd on
$ curl localhost
okFluentdと各種プラグインをインストールします。
$ curl -L http://toolbelt.treasuredata.com/sh/install-redhat.sh | sh
$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-norikra --no-ri --no-rdocFluentdの設定ファイルを編集し、ApacheのアクセスログをNorikraに流し込むようにします。
最初に説明した手順①、②の部分の設定です。
$ sudo chmod a+rx /var/log/httpd
$ sudo mkdir /etc/td-agent/pos
$ sudo chown td-agent:td-agent /etc/td-agent/pos
$ cat /etc/td-agent/td-agent.conf
<source>
type tail
format /^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$/
time_format %d/%b/%Y:%H:%M:%S %z
path /var/log/httpd/access_log
tag apache.access
pos_file /etc/td-agent/pos/apache.access_log
</source>
<match apache.access>
type norikra
norikra localhost:26571
buffer_queue_limit 1
retry_limit 0
remove_tag_prefix apache
target_map_tag true
</match>最初に、Fluentdのin_tailプラグイン用にディレクトリの作成や権限変更を行っています。
Fluentd設定の後半で、Norikraへのログの流し込みを設定しています。Fluetndのタグ名がNorikraのターゲット名になるようにしつつ、タグプレフィックス「apache」を削除するようにしているので、「access」というターゲットがNorikraに作られるようになるはずです。
これで、アクセスログをNorikraに流し込む準備ができたので、100回くらいアクセスして動作を見てみましょう。
$ ab -c 10 -n 100 http://`curl ifconfig.me`/index.htmlウェブUIを見ると、新たに「access」というターゲットが出来ていることが確認できます。
IPアドレス毎の1分間のアクセス数を取得するクエリを追加してみます。
SELECT
host,
COUNT(*)
FROM access.win:time_batch(1 min)
GROUP BY hostというクエリを登録しています。
ほぼSQLの集約クエリと同じですが、ターゲット名「access」に続くデータウィンドウ「.win:time_batch(1 min)」の部分で、１分毎の集計を行うように指定しています。
データウィンドウの一覧はEsperのドキュメントで確認できます。EsperとはNorikraが利用しているイベント処理エンジンです。
クエリの登録がすんだら、何回かアクセスして、結果を見てみましょう。
$ date
Tue Apr 1 05:33:24 UTC 2014
$ ab -c 10 -n 100 http://`curl ifconfig.me`/index.html
$ date
Tue Apr 1 05:34:44 UTC 2014
$ ab -c 10 -n 200 http://`curl ifconfig.me`/index.html最初に100アクセス、１分後に200アクセスしてみました。出力を確認するとと、
$ norikra-client event fetch access_count_per_1min
{"time":"2014/04/01 05:34:01","host":"54.199.254.150","count(*)":100}
{"time":"2014/04/01 05:35:01","host":"54.199.254.150","count(*)":200}
{"time":"2014/04/01 05:36:01","host":"54.199.254.150","count(*)":0}期待通りの結果が得られました。
DoS攻撃検知用クエリの設定
それでは、手順③、NorikraでDoS攻撃を検知する設定に進みます。
今回は「同じIPアドレスから1分間に1,000リクエストあった場合」攻撃と見なすようしました。
Norikraのクエリは次のようになります。
block.access_over_1000_per_1min
SELECT
host,
COUNT(*) as requests
FROM access.win:time_batch(1 min)
GROUP BY host
HAVING COUNT(*) >= 1000
最初に500アクセス、少し時間をおいて1000アクセスしてみます。
$ date
Tue Apr 1 05:59:16 UTC 2014
$ ab -c 100 -n 500 http://`curl ifconfig.me`/index.html
$ date
Tue Apr 1 06:01:22 UTC 2014
$ ab -c 100 -n 1000 http://`curl ifconfig.me`/index.html結果を取得してみましょう。
$ norikra-client event fetch block.access_over_1000_per_1min
{"time":"2014/04/01 06:02:19","requests":1000,"host":"54.199.254.150"}ちゃんと1000アクセスした場合のみ取得できています。念のため、アクセス数で絞り込みしてないクエリの結果も見てみましょう。
$ norikra-client event fetch access_count_per_1min
{"time":"2014/04/01 06:00:01","host":"54.199.254.150","count(*)":500}
{"time":"2014/04/01 06:01:01","host":"54.199.254.150","count(*)":0}
{"time":"2014/04/01 06:02:01","host":"::1","count(*)":1}
{"time":"2014/04/01 06:02:01","host":"54.199.254.150","count(*)":1000}
{"time":"2014/04/01 06:03:01","host":"::1","count(*)":0}
{"time":"2014/04/01 06:03:01","host":"54.199.254.150","count(*)":0}こちらでは500リクエストの場合も取得できています。期待通りです。
DoS攻撃ブロック設定
DoS攻撃を検知できるようになったので、次に検知されたIPアドレスをブロックする仕組みを作ります。手順④の部分です。
まず、Fluentdの設定に下記ディレクティブを追記し、Norikraから結果を取得し、その結果を外部スクリプトに渡すようにします。
<source>
type norikra
norikra localhost:26571
<fetch>
method sweep
tag query_name
tag_prefix norikra.query
interval 60s
</fetch>
</source>
<match norikra.query.block.*>
type exec_filter
command /usr/local/bin/blocker ec2.ap-northeast-1.amazonaws.com acl-77527b1f block
in_format json
out_format msgpack
tag access.blocked
</match>前半のsourceディレクティブはNorikraから結果を取得する部分です。60秒に1回、全結果を取得し、「norikra.query」というタグプレフィックスがつくようにしています。タグにはNorikraのクエリ名もつくので、実際のタグは「norikra.query.count_access」や「norikra.query.block.access_over_1000_per_1min」の様になります。
後半のディレクティブはNorikraから受け取った結果イベントを外部スクリプトに渡す部分です。
「/usr/local/bin/blocker」というスクリプト内の処理でAWSのNetwork ACLの設定を変更し、受け取ったIPドレスからの接続を拒否するようにしています。引数として、
- 第1引数(必須)：EC2のエンドポイント
- 第2引数(必須)：Network ACLのID
- 第3引数(任意)：ブロックフラグ(ブロックする場合「block」と指定)
-
を取ります。
外部スクリプトからの結果には、「access.blocked」というタグがつけられます。
外部スクリプトの内容は次のようになります。
/usr/local/bin/blocker
#!/usr/lib64/fluent/ruby/bin/ruby
require 'aws-sdk'
require 'json'
require 'msgpack'
$stdout.sync = true
endpoint = ARGV[0]
acl_id = ARGV[1]
block = ARGV[2] == 'block'
ec2 = AWS::EC2.new(ec2_endpoint: endpoint)
acl = ec2.network_acls[acl_id]
while input = STDIN.gets
begin
attacker = JSON.parse(input)
rescue
next
end
if block
begin
allow_any_rule = acl.entries.
select {|r|
r.ingress &&
r.action == :allow &&
r.protocol == -1 &&
r.cidr_block == "0.0.0.0/0"
}.
sort_by {|r| r.rule_number}.
first
deny_rules = acl.entries.
select {|r|
r.ingress &&
r.action == :deny &&
r.rule_number < allow_any_rule.rule_number
}.
sort_by {|r| r.rule_number}
next_rule_number = deny_rules.empty? ? 1 : deny_rules.last.rule_number + 1
unless deny_rules.any? {|r| r.cidr_block == "#{attacker['host']}/32"}
acl.create_entry(
rule_number: next_rule_number,
action: 'deny',
protocol: -1,
cidr_block: "#{attacker['host']}/32",
egress: false,
)
end
attacker[:status] = 'blocked'
rescue
attacker[:status] = 'failed to block'
end
else
attacker[:status] = 'detected'
end
attacker[:proccessed_at] = Time.now.to_s
print MessagePack.pack(attacker)
end実行権限を付与しておきます。
$ sudo chmod a+x /usr/local/bin/blockerAWSのNetwork ACLはマネジメントコンソールから確認できます。
現在は、どこからのアクセスも許可している状態です。
では、実際、ブロックされるか確認してみます。
設定を反映させるため、Fluentdを再起動し、
$ sudo service td-agent restart1000回アクセスしてみます。
$ curl ifconfig.me
54.199.254.150
$ ab -c 100 -n 1000 http://`curl ifconfig.me`/index.html1分ほどたってから、マネジメントコンソールを再読み込みしてみると、アクセス元である「54.199.254.150」がブロックされているのが確認できます。
Network ACLのルールはルール番号の小さい方から適応されます。ですので、全許可ルール(100番)の１つ手前まで99個の拒否ルールを作ることが可能です。
より多くのIPアドレスを拒否したい場合は、全許可ルールの番号を大きくするとよいでしょう。
念のため、cURLコマンドでアクセスできるか試してみます。
$ curl http://`curl ifconfig.me`/index.html
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 15 0 15 0 0 280 0 --:--:-- --:--:-- --:--:-- 283
curl: (7) Failed to connect to 54.199.254.150 port 80: Connection timed outちゃんとブロックされてますね。
ブロック結果の通知設定
最後に、ブロックの結果をSNSで通知するようにしましょう。手順の⑤にあたる部分です。
Fluentdのプラグインをインストールします。
$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-sns --no-ri --no-rdocFluentdの設定ファイルにSNS用のディレクティブを追加します。
あらかじめSNSトピックを作り自分のメールアドレスをサブスクライバに登録しておいてください。
/etc/td-agent/td-agent.conf
<match access.blocked>
type sns
sns_topic_name test
sns_endpoint sns.ap-northeast-1.amazonaws.com
sns_subject block_host #constant subject
</match>「test」という名前のSNSトピックに「block_host」というタイトルで通知が飛ぶようにしました。
先ほど、Network ACLに追加されたDenyルールを削除し、Fluentdを再起動した後、もう一度動作確認します。
$ ab -c 100 -n 1000 http://`curl ifconfig.me`/index.htmlしばらくすると、SNSのサブスクライバに登録したメールアドレス宛に次のようなメールが届きました。
{"requests":1000,"host":"54.199.254.150","status":"blocked","proccessed_at":"2014-04-01 08:15:50 +0000","time":"2014-04-01 08:15:50 +0000"}
--
If you wish to stop receiving notifications from this topic, please click or visit the link below to unsubscribe:
https://sns.ap-northeast-1.amazonaws.com/unsubscribe.html?SubscriptionArn=xxxxxxxxxx
Please do not reply directly to this e-mail. If you have any questions or comments regarding this email, please contact us at sns-question@amazon.comFluentdの設定ファイルをまとめると次のようになります。
<source>
type tail
format /^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$/
time_format %d/%b/%Y:%H:%M:%S %z
path /var/log/httpd/access_log
tag apache.access
pos_file /etc/td-agent/pos/apache.access_log
</source>
<match apache.access>
type norikra
norikra localhost:26571
buffer_queue_limit 1
retry_limit 0
remove_tag_prefix apache
target_map_tag true
</match>
<source>
type norikra
norikra localhost:26571
<fetch>
method sweep
tag query_name
tag_prefix norikra.query
interval 60s
</fetch>
</source>
<match norikra.query.block.*>
type exec_filter
command /usr/local/bin/blocker ec2.ap-northeast-1.amazonaws.com <<Network ACL ID>> block
in_format json
out_format msgpack
tag access.blocked
</match>
<match access.blocked>
type sns
sns_topic_name <<SNS Topic Name>>
sns_endpoint sns.ap-northeast-1.amazonaws.com
sns_subject block_host #constant subject
</match>
<match norikra.query.detect.*>
type exec_filter
command /usr/local/bin/blocker ec2.ap-northeast-1.amazonaws.com <<Network ACL ID>>
in_format json
out_format msgpack
tag access.detected
</match>
<match access.detected>
type sns
sns_topic_name <<SNS Topic Name>>
sns_endpoint sns.ap-northeast-1.amazonaws.com
sns_subject detect_host #constant subject
</match>まとめ
DoS攻撃を検知し、ブロックする仕組みを作ってみました。
Norikuraを使うのは今回が初めてですが、簡単にクエリを追加、削除できるのが楽しいですね。
SQLと似ているので、何となくで書いても大体動きます。
フィールドタイプの判別も自動でやってくれるので、フィールドが増減した場合も特に対応は必要無さそうです。
例えば、ブルートフォース攻撃を防ぎたいと思った場合、
- ログイン失敗をアクセスログに出力するようにする
- Fluentdのin_tailディレクティブのformatを修正
- Norikraでクエリ追加
だけで対応できます。
クエリはこんな感じでしょうか。
block.login_failed_over_60_per_1min
SELECT
host,
COUNT(*) AS login_failed
FROM access.win:time_batch(1 min)
WHERE auth = 'failed'
GROUP BY host
HAVING COUNT(*) >= 60Norikraのインストールは10分もあればできるので、皆さんもぜひ使ってみてください。
16
