我最近开始将公司的一些服务器迁移到 Google 的计算引擎。除此之外，我还设置了一个 2 节点的 elasticsearch 集群。
今天我在其中一个节点上运行 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.
因此，您可能能够看到通过哪个脚本删除了文件。另一种可能性是密码较差的特权 ftp 帐户。还搜索这些日志...
答案2
顺便说一句，Elasticsearch 在向互联网开放时并不安全。不确定你的是否是，只是想我应该指出这一点。
“使用防火墙始终很重要。elasticsearch http 模块的设计目的不是暴露于不受信任的网络，因为它不提供授权，也不提供身份验证机制。默认情况下，elasticsearch 监听两个端口：9200/tcp（restful api）和 9300 /tcp（用于 java 节点/传输客户端以及集群中节点之间的通信）。” （https://groups.google.com/forum/#!topic/ica-atom-users/zkZqqTULvn4）