es数据被黑事件记录和处理

发表于   |   分类于   |  

现象

时间: 2020年8月30日 4点10分

es中所有open的日志全被删掉，包括系统日志，只留下一个read_me

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
{
  "read_me": {
    "aliases": {},
    "mappings": {
      "_doc": {
        "properties": {
          "@timestamp": {
            "type": "date"
          },
          "message": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          }
        }
      }
    },
    "settings": {
      "index": {
        "creation_date": "1598760619467",
        "number_of_shards": "5",
        "number_of_replicas": "1",
        "uuid": "cL_kgJ_XQqe2lSgOrN4VUw",
        "version": {
          "created": "6030299"
        },
        "provided_name": "read_me"
      }
    }
  }
}
"message": "SEND 0.015 BTC TO THIS WALLET: 1BJxnAYaaWNbQcL9o9GS768v3VqVMNDusD IF YOU WANT RECOVER YOUR DATABASE! SEND TO THIS EMAIL YOUR SERVER IP AFTER SENDING THE BITCOINS getbase@cock.li"

网络i/o没有突增，所以数据并没有被移走，而是直接被删掉了

影响

数据丢失：es所在云盘有快照备份，可以从28号早上五点的恢复，丢失数据即28，29号和30号一部分，周末基本无日志，所以主要损失28号当前的请求日志

修复成本: 导出30号之后的日志，然后回滚磁盘，操作简单但耗时较长，预计影响时间3小时，后期考虑是否更换云盘类型，提高备份和回滚速度

漏洞查找

  • es没有密码保护

操作es有三种个途径，一是ip直接访问，二是通过内网slb访问，三是使用kibana

这三者都在内网中需要ecs安全组访问白名单，检查不存在大范围的ip授权，除了阿里云自动添加的ip段较大（到24位），但平时添加公司ip过期没有及时删除

检索slb中与发生时间相近的日志，条件过滤request_method: DELETE,查到了大量删除请求,再根据http_user_agent: python-requests/2.18.4为条件过滤得到了完整的攻击请求

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
08-28 23:38:25
client_ip:  195.54.161.252
client_port:  60516
http_host:   *.*.*.*:9200
http_user_agent:  python-requests/2.18.4
request_method:  HEAD
request_uri:  /
slb_vport:  9200
time:  2020-08-28T23:38:25+08:00
upstream_addr:  *.*.*.*:32101
vip_addr:   *.*.*.*
08-28 23:38:28
client_ip:  195.54.161.252
client_port:  39732
http_host:  *.*.*.*:9200
http_user_agent:  python-requests/2.18.4
request_method:  GET
request_uri:  /_all/
slb_vport:  9200
time:  2020-08-30T12:10:19+08:00
upstream_addr: *.*.*.*
vip_addr:  *.*.*.*
08-28 23:38:36
client_ip:  195.54.161.252
client_port:  32844
http_host:  *.*.*.*:9200
http_user_agent:  python-requests/2.18.4
request_method:  DELETE
request_uri:  /log_saas_develop-2020.07.21/
slb_vport:  9200
time:  2020-08-28T23:38:36+08:00
upstream_addr:  *.*.*.*:32101
vip_addr:  *.*.*.*
...

一共发起了两次攻击，第一次发生在08-28 23:38:25,第二次是在08-30 12:10:19

http_host是一个公网ip，一开始在slb和ecs中都没查到，后来发现是我使用的阿里云子账号权限不够看不到EIP =_=||

漏洞: 内网slb绑定了公网eip，没有访问控制，也没有改es默认端口,被暴利扫描的脚本发现

问题处理

出现问题的原因: 原先es绑定的内网slb是单纯为es使用端口设为默认9200，方便内网中其他服务通过域名访问到es，后被合并到slb ops-k8s-cluster，但该slb是绑定在k8s上并提供了EIP给k8s的api server，导致es暴露到公网中，没有访问控制且未修改端口

处理方法: 增加访问控制，采用和ecs相同的方式刷白名单，不使用默认端口9200

总结

未被保护的资产暴露到公网被暴力扫描脚本攻击

发现问题与自检

  1. 暴露公网ip的服务（slb,ecs,rds）必须配置访问控制
  2. 自建的公共服务（es,redis,gitlab,jenkins,spinnaker等）禁止使用默认端口
  3. 自建服务只能通过域名访问，避免无访问记录
  4. 云盘快照备份中只备份工作日的配置不合理，原先是周一到周五，需改为周二到周六
  5. 定期更换服务密码