elasticsearchをランサムウェアから守るには #elastic

こんにちは。木内です。年末から十分に設定されていないMongoDBをターゲットにしデータを消去したうえで、復元料を要求する攻撃が続いています。最近同様の攻撃と思われるものが elasticsearch にも行われていることがわかりました。

[MongoDBに関する情報]
ZDNet Japan - 「MongoDB」狙うランサムウェア攻撃で2万7000超のデータベースが被害に--研究者ら報告
http://japan.zdnet.com/article/35094721/

[elasticsearchに関する情報]
Elastic Forum - Ransom attack on Elasticsearch cluster?
https://discuss.elastic.co/t/ransom-attack-on-elasticsearch-cluster/71310
PC World - After MongoDB, ransomware groups hit exposed Elasticsearch clusters
http://www.pcworld.com/article/3157417/security/after-mongodb-ransomware-groups-hit-exposed-elasticsearch-clusters.html

そこで改めて、完璧な対策になるわけではありませんが elasticsearch への不正なアクセスを抑止する方法をご紹介いたします。

Elasticsearchのユーザ認証機能について

elasticsearchのインデックスへのアクセスを限られたユーザだけに提供する機能は、残念ながら 有償プラグインである X-Pack に含まれる Security(旧名 Shield) でしか提供されていません。

ユーザ認証がなくてもできることはあります

オープンソース版の elasticsearch には残念ながらユーザ認証機能はありません。しかし不正なアクセスからデータを守るためにできることがいくつかあります。

まず何よりも、 elaticsearch クラスタにインターネットのどこからでもアクセスできる状況にしてはいけません 。そのための設定をいくつかご紹介します。

アクセスを受け付けるIPアドレス, ポート番号を制限する

elaticsearchの設定( 多くの場合、 /etc/elasticsearch/elasticsearch.yml )を確認しましょう。確認する項目は network.host です(環境によっては network.bind_host になっているかもしれません)。 ここに設定されたIPアドレスが割り当てられたネットワークインターフェイスからの問い合わせを受け付けます。 localhost もしくは 127.0.0.1 がもっとも安全な選択ですが、諸々の事情で何かしら外部からのアクセスを受け付けざるを得ない場合は、必ず信頼できるホストが所属しているネットワークのプライベートIPアドレスを割り当てるようにしましょう。 決して network.host に 0.0.0.0 と設定してはいけません。この場合 elasticsearch はどのアドレスからのアクセスも受け付けてしまいます。必ず最小限の、信頼できるホストが所属しているネットワークのプライベートIPアドレスを割り当てるようにしましょう。

ポート番号もデフォルトの値(9200)から変えておくと、攻撃者はあなたの elasticsearch クラスタを見つけることが若干ではありますが困難になるでしょう。/etc/elasticsearch/elasticsearch.yml の項目名は、http.port です。ポート番号を変更した場合は、下記のクライアントの設定も合わせて変更することをお忘れなく。

iptables, firewalldでアクセス可能なSource IPアドレスや、到達可能なポート番号を絞り込むことも可能です。多くのLinuxディストリビューションではわかりやすい設定ガイドが公開されています( 参考: https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html )。

AWS や Microsoft Azure などのパブリッククラウドを使用している場合は注意しましょう。インスタンスに割り当てられているIPアドレスがプライベートIPアドレスでも、グローバルIPアドレスへのアクセスがそのままインスタンスにフォワードされる設定になっているかもしれません。インスタンスのグローバルアドレスに関する設定や、セキュリティグループに関する設定をもう一度確認してみてください。

Kibanaなどのクライアント設定を確認する

elasticsearchのアクセス制限を設定してもまだ不十分です。elasticsearchにアクセス可能なクライアントに誰でもアクセス可能な状態では、クライアントからelasticsearchに攻撃を行われる可能性があります。 例えばKibanaでは、Dev Tools(旧名 Sense)を経由することで、elasticsearchのインデックスを直接操作することができます。

例えばKibanaの場合は、設定ファイル /etc/kibana/kibana.yml を編集することでブラウザからのアクセスを受け付けるIPアドレス、ポート番号を指定することができます。項目名は server.port と server.host です。特に server.host には注意してください。 0.0.0.0 としていた場合、どのアドレスからのアクセスも受け付けてしまいます。必ず最小限の、信頼できるホストが所属しているネットワークのプライベートIPアドレスを割り当てるようにしましょう。elasticsearchの場合と同様に、iptables, firewalldでアクセス可能なSource IPアドレスや、到達可能なポート番号を絞り込むこともよいでしょう。

利便性とのトレードオフにはなりますが、Dev Toolsを無効にすることもできます。 /etc/kibana/kibana.yml の console.enabled を false にすることでDev Toolsを無効にすることができます。

elasticsearchの場合と同様に、AWS や Microsoft Azure などのパブリッククラウドを使用している場合はインスタンスのグローバルアドレスに関する設定や、セキュリティグループに関する設定をもう一度確認してみてください。

上記で elasticsearch のアクセスポート番号を変更した場合は、 elasticsearch.url の該当部分を変更してください。

さらにKibanaなどのクライアントへのアクセスを、WebリバースプロキシやVPN経由のアクセスに限定することで安全性が高まります。

そのほか考えること

言わずもがなかもしれませんが、不要な elasticsearch クラスタを削除したり、特に誰でもアクセスされる環境に置く必要のない elasticsearch クラスタをプライベートネットワーク内に配置するなどの処置を行いましょう。

宣伝文句にはなってしまいますが、どうしてもユーザ認証などの保護を入れる必要がある場合には、有償サブスクリプションの購入を検討してもいいかもしれません。

さいごに

elasticsearch は優れた機能を持つソフトウェアですが、設定がルーズであるためにデータを危険にさらす可能性もあります。これを機にもう一度、環境をチェックしてみましょう。

Elastic社では Securing Your Elasticsearch Cluster というブログ記事を公開しています。ランサム攻撃に限らない包括的なセキュリティ確保のための手法が記述されていますので是非参考にしてみてください。