震惊！我差点把公司ES数据裸奔在公网——ES未授权漏洞复现全记录
哼,说实话，写这篇文章的时候我手心还冒着冷汗呢，上周五加班到深夜，我为了图省事，居然把Elasticsearch的9200端口直接映射到了公网IP上——那一刻我完全没意识到，这几乎成了我职业生涯的“至暗时刻” 。
起因：一个“偷懒”引发的血案
事情是这样的,当时线上环境有个日志检索需求特别急，我寻思着“反正是内网测试环境，先映射出去联调一下应该没事吧”？结果呢，嘿，第二天一早打开Kibana，我整个人都傻了——数据索引莫名其妙的多了好几个，而且都是我不认识的！
再一看访问日志,好家伙，来自世界各地的好几十个IP轮番扫描我的9200端口，我当时心里“咯噔”一下，完了，大概率是ES未授权访问漏洞被人家利用了，哎呀，那种感觉，真的跟吃了苍蝇一样难受。
复现过程：一步步捅破窗户纸
为了搞清楚黑客是怎么做到的,我拉了个隔离环境的靶机，决定把这个 “ES未授权漏洞复现” 的完整攻击链给走一遍，也算给大家提个醒。
第一步：端口探测（心跳加速的开始）
我用Nmap扫了一下目标IP的9200端口,返回状态是open，看着这结果，我心里既兴奋又害怕——兴奋的是漏洞复现环境搭建成功，害怕的是这要是生产环境，我可能当场就得卷铺盖走人。
第二步：直接请求根路径（冷汗直流的瞬间）
接着我用浏览器或者curl直接访问：
curl http://target-ip:9200/
你猜怎么着？服务器直接返回了一串大JSON，里头赫然写着"cluster_name" : "my_es"，还有各种版本号信息，那种感觉就像是你没带钥匙，结果发现人家大门压根就没锁！真的，不夸张的说，我后背当时就湿了。
第三步：查看所有索引（彻底无语）
然后我尝试访问：
curl http://target-ip:9200/_cat/indices?v
舒服了！所有索引名、文档数、存储大小，一览无遗！连个像样的身份验证都没得，我当时忍不住爆了句粗口：“卧槽，这跟把银行卡密码写在银行卡背面有啥区别啊？”
第四步：删库跑路测试（侥幸好运）
更吓人的是,我尝试用DELETE请求删掉一个测试索引，居然也成功了！虽然靶机数据无所谓，但我瞬间联想到之前某大厂被删库的新闻，估计也是这么个流程吧，唉，做安全测试的时候心里真的是七上八下的。
深度剖析：为啥会这样？
说白了,ES在默认配置下，压根就没打算开认证，http.cors.enabled 和 network.host 如果配置不当（比如设置成0.0.0），再不对elasticsearch.yml做安全加固，那就等于给全网黑客递刀子呀！我这次复现用的版本是7.x，虽然官方后来加了X-Pack，但免费版基础认证还是要自己动手开的，要是我当初多看一眼文档，也不至于吓得半夜惊醒。
急救方案与血泪总结
如果你现在也觉得自建ES端口暴露在公网没事,赶紧的，照着以下操作急救：
- 绑定内网IP：把
network.host改为内网地址，千万别碰0.0.0。 - 开启X-Pack安全：在
elasticsearch.yml里加xpack.security.enabled: true，然后设置密码。 - 防火墙白名单：在安全组里只允许特定跳板机IP访问9200端口。
- 使用反向代理：如果非要公网访问，套一层Nginx加上Basic Auth，别让ES裸奔。
说到底，这次ES未授权漏洞复现，给我上了极其生动的一课。 做技术的真不能心存侥幸，一个误配置就可能造成数据大泄露，各位兄弟姐妹，你们有没有遇到过类似因为“顺手”导致的惊魂时刻？评论区聊聊呗，让我知道我不是一个人在作死的边缘试探过……
最后喊一嗓子,如果有需要详细的ES未授权漏洞复现详细截图和修复配置文档的，可以在公众号后台回复“ES加固”，我整理了一份PDF手册，亲测有效，希望能帮你避坑！唉，不说了，我去给Kibana改密码了，再见再见！