私は最近、会社のサーバーの一部をGoogleのCompute Engineに移行し始めました。これに加えて、2ノードのElasticsearchクラスタも設定しました。
今日、私はノードの1つでtopコマンドを実行していましたが、いくつかの疑わしいプロセスが見つかりました。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11995 elastics 20 0 424m 25m 400 S 533.0 0.1 877:26.82 gg
30494 elastics 20 0 23.4g 16g 116m S 0.8 56.7 2:49.61 java
20148 newrelic 20 0 244m 5824 2872 S 0.5 0.0 9:34.29 nrsysmond
42 root 20 0 0 0 0 S 0.3 0.0 0:41.16 events/7
4 root 20 0 0 0 0 S 0.1 0.0 0:54.41 ksoftirqd/0
38 root 20 0 0 0 0 S 0.1 0.0 0:22.52 events/3
39 root 20 0 0 0 0 S 0.1 0.0 0:20.27 events/4
2876 root 20 0 15152 1312 928 R 0.1 0.0 0:00.10 top
7022 elastics 20 0 424m 16m 380 S 0.1 0.1 1:10.45 freeBSD
1 root 20 0 19340 1312 952 S 0.0 0.0 0:02.38 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.12 kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:01.44 migration/0
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 stopper/0
ID 11995と7022のプロセスが疑わしく、もう少し詳しく調べることにしました。
このプロセスでlsofを実行すると、すでに中国や香港に接続されていることがわかります。
以下でサンプルスニペットを見つけます。
[root@elastic-prd-node-01 fail2ban]# lsof -p 11995
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
gg 11995 elasticsearch cwd DIR 8,1 4096 2 /
gg 11995 elasticsearch rtd DIR 8,1 4096 2 /
gg 11995 elasticsearch txt REG 8,1 1415201 16117 /tmp/gg (deleted)
gg 11995 elasticsearch mem REG 8,1 99154480 4784 /usr/lib/locale/locale-archive
gg 11995 elasticsearch 0u CHR 1,3 0t0 3881 /dev/null
gg 11995 elasticsearch 1u CHR 1,3 0t0 3881 /dev/null
gg 11995 elasticsearch 2u CHR 1,3 0t0 3881 /dev/null
gg 11995 elasticsearch 3u IPv4 10615541 0t0 TCP myservername.c.myproject.internal:54431->103.206.22.224:28099 (ESTABLISHED)
gg 11995 elasticsearch 4u IPv4 10656374 0t0 UDP *:49882
gg 11995 elasticsearch 5u IPv4 10656375 0t0 UDP *:41943
gg 11995 elasticsearch 6u IPv4 10656376 0t0 UDP *:49792
gg 11995 elasticsearch 7u IPv4 10656377 0t0 UDP *:32849
gg 11995 elasticsearch 8u IPv4 10656378 0t0 UDP *:35841
gg 11995 elasticsearch 9u IPv4 10656379 0t0 UDP *:52037
gg 11995 elasticsearch 10u IPv4 10656380 0t0 UDP *:45405
gg 11995 elasticsearch 11u IPv4 10656381 0t0 UDP *:55345
gg 11995 elasticsearch 12u IPv4 10656382 0t0 UDP *:49990
gg 11995 elasticsearch 13u IPv4 10656383 0t0 UDP *:34888
gg 11995 elasticsearch 14u IPv4 10656384 0t0 UDP *:46642
gg 11995 elasticsearch 15u IPv4 10656385 0t0 UDP *:38881
gg 11995 elasticsearch 16u IPv4 10656386 0t0 UDP *:38455
gg 11995 elasticsearch 17u IPv4 10656387 0t0 UDP *:47360
gg 11995 elasticsearch 18u IPv4 10656388 0t0 UDP *:40310
gg 11995 elasticsearch 19u IPv4 10656389 0t0 UDP *:44127
gg 11995 elasticsearch 20u IPv4 10656390 0t0 UDP *:46064
gg 11995 elasticsearch 21u IPv4 10656391 0t0 UDP *:55830
gg 11995 elasticsearch 22u IPv4 10656392 0t0 UDP *:43110
gg 11995 elasticsearch 23u IPv4 10656393 0t0 UDP *:58793
私も以下を実行しました。
[root@elastic-prd-node-01 tmp]# ls -al /proc/11995/exe
lrwxrwxrwx. 1 elasticsearch elasticsearch 0 May 8 12:48 /proc/17525/exe -> /tmp/gg
/tmpそのディレクトリにgg、freeBSD、またはsyn2016という名前の疑わしいファイルが見つかりました。
その後、/tmpディレクトリ全体を処理し、疑わしいプロセスをすべて終了し、/tmpから疑わしいファイルをすべて削除し、サーバーをシャットダウンしました。
次は何をすべきですか？これは正常に見えますか？攻撃のように見えますか？今後このようなことが再発しないようにするにはどうすればよいですか？真実を把握するためにどのような措置を講じることができますか？
ps私はelasticsearch 1.6.2を実行しておりCentOS 6、elasticdumpを使用してインデックスを移行しています。
答え1
これは確かに攻撃です。誰かが管理した
a) drop a file onto your server (possibly via poorly configured apache)
b) execute that file
あなたがしなければならないこと：
a) mount the /tmp partition with the noexec - option
b) reboot the server
c) run a malware scan on the complete host while offline
d) if that does not help : REINSTALL from scratch
それを深く理解するには:
a) check the gg file's creation date
b) look into the httpd-logs at that time.
したがって、どのスクリプトがファイルを削除したかを確認できます。もう1つの可能性は、パスワードが正しくない特権のあるFTPアカウントです。このログも検索してみてください...
答え2
ところで、Elasticsearchはインターネットに公開されていれば安全ではありません。あなたが正しいかどうかはわかりませんが、指摘する必要があると思いました。
「常にファイアウォールを使用することが重要です。Elasticsearch httpモジュールは認証を提供せず、認証メカニズムも提供しないため、信頼できないネットワークにさらされるように設計されていません。デフォルトでは、Elasticsearchは2つのポート（9200 / tcp（安定） API）と9300 / tcp（Javaノード/トランスポートクライアントとクラスタのノード間の通信用）」（https://groups.google.com/forum/#!topic/ica-atom-users/zkZqqTULvn4)