有个人长的像洋葱，走着走着就哭了…….
安全

安全

开启安全功能 ES 集群就安全了吗？

Easysearch • yangmf2040 发表了文章 • 0 个评论 • 3870 次浏览 • 2023-12-27 10:38 • 来自相关话题

背景

经常跟 ES 打交道的朋友都知道，现在主流的 ES 集群安全方案是：RBAC + TLS for Internal + HTTPS 。

作为终端用户一般只需要关心用户名和密码就行了。作为管理和运维 ES 的人员来说，可能希望 ES 能提供密码策略来强制密码强度和密码使用周期。遗憾的是 ES 对密码强度和密码使用周期没有任何强制要求。如果不注意，可能我们天天都在使用“弱密码”或从不修改的密码（直到无法登录）。而且 ES 对连续的认证失败，不会做任何处理，这让 ES 很容易遭受暴力破解的入侵。

那还有没有别的办法，进一步提高安全呢？ 其实，网关可以来帮忙。

虽然网关无法强制提高密码复杂度，但可以提高 ES 集群被暴力破解的难度。

大家都知道，暴力破解--本质就是不停的“猜”你的密码。以现在的 CPU 算力，一秒钟“猜”个几千上万次不过是洒洒水，而且 CPU 监控都不带波动的，很难发现异常。从这里入手，一方面，网关可以延长认证失败的过程--延迟返回结果，让破解不再暴力。另一方面，网关可以记录认证失败的情况，做到实时监控，有条件的告警。一旦出现苗头，可以使用网关阻断该 IP 或用户发来的任何请求。

场景模拟

首先，用网关代理 ES 集群，并在 default_flow 中增加一段 response_status_filter 过滤器配置，对返回码是 401 的请求，跳转到 rate_limit_flow 进行降速，延迟 5 秒返回。

  - name: default_flow
    filter:
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
      - response_status_filter:
          exclude:
            - 401
          action: redirect_flow
          flow: rate_limit_flow
  - name: rate_limit_flow
    filter:
      - sleep:
          sleep_in_million_seconds: 5000

其次，对于失败的认证，我们可以通过 Console 来做个看板实时分析，展示。

折线图、饼图图、柱状图等，多种展示方式，大家可充分发挥。

最后，可在 Console 的告警中心，配置对应的告警规则，实时监控该类事件，方便及时跟进处置。

效果测试

先带上正确的用户名密码测试，看看返回速度。

0.011 秒返回。再使用错误的密码测试。

整整 5 秒多后，才回返结果。如果要暴力破解，每 5 秒钟甚至更久才尝试一个密码，这还叫暴力吗？

看板示例

此处仅仅是抛砖引玉，欢迎大家发挥想象。

告警示例

建立告警规则，用户 1 分钟内超过 3 次登录失败，就产生告警。

可在告警中心查看详情，也可将告警推送至微信、钉钉、飞书、邮件等。

查看告警详情，是 es 用户触发了告警。

最后，剩下的工作就是对该账号的处置了。如果有需要可以考虑阻止该用户或 IP 的请求，对应的过滤器文档在这里，老规矩加到 default_flow 里就行了。

如果小伙伴有其他办法提升 ES 集群安全，欢迎和我们一起讨论、交流。我们的宗旨是：让搜索更简单！

【警惕】Grafana 0day 高危漏洞已爆出，尽快处理

资讯动态 • medcl 发表了文章 • 0 个评论 • 2517 次浏览 • 2021-12-14 10:11 • 来自相关话题

来源：https://www.freebuf.com/vuls/307891.html   一、漏洞概况 Grafana是一个跨平台的开源的度量分析和可视化工具，可以通过将采集的数据查询然后可视化的展示，并及时通知。它主要有以下六大特点： 1、展示方式：快速灵活的客户端图表，面板插件有许多不同方式的可视化指标和日志，官方库中具有丰富的仪表盘插件，比如热图、折线图、图表等多种展示方式； 2、数据源：Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch和KairosDB等； 3、通知提醒：以可视方式定义最重要指标的警报规则，Grafana将不断计算并发送通知，在数据达到阈值时通过Slack、PagerDuty等获得通知； 4、混合展示：在同一图表中混合使用不同的数据源，可以基于每个查询指定数据源，甚至自定义数据源； 5、注释：使用来自不同数据源的丰富事件注释图表，将鼠标悬停在事件上会显示完整的事件元数据和标记； 6、过滤器：Ad-hoc过滤器允许动态创建新的键/值过滤器，这些过滤器会自动应用于使用该数据源的所有查询。 二、漏洞分析 此次受影响的版本如下： Grafana 是否受影响 8.x 是 漏洞由grafana-main\pkg\api\api.go引起
1639011455_61b1547fd88db6e6a34c4.png
分析原因： api功能可以实现加载插件文件，然后返回文件内容 由于加载路径时候未进行过滤，导致../实现任意文件读取。
1639011486_61b1549e779dae64bdd3a.png
最后返回文件内容：
1639011521_61b154c188615e1b0dd3f.png
二、漏洞利用 GET /public/plugins/welcome/../../../../../../../../etc/passwd HTTP/1.1 Host: 127.0.0.1:3000 Content-Length: 21 Connection: close
1639011659_61b1554bb48bb99945d6f.png
三、漏洞评估 公开程度：已出现在野利用 利用条件：无权限要求 交互要求：0 click 漏洞危害：高危、任意文件读取 影响范围：Grafana 8.x 四、修复方案   1、目前厂商暂未修复，建议对../以及相关编码进行过滤。 2、上waf 3、加反向代理利用中间件对路径做normalize操作。

使用极限网关来处置 Elasticsearch 的 Apache Log4j 漏洞

Elasticsearch • medcl 发表了文章 • 2 个评论 • 6712 次浏览 • 2021-12-11 03:57 • 来自相关话题

昨日爆出的 Log4j 安全漏洞，业界一片哗然，今天给大家介绍一下，如何使用极限网关来快速处置 Elasticsearch 的 Apache Log4j 漏洞。

【CVE 地址】

https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

【漏洞描述】

Apache Log4j 是一款非常流行的开源的用于 Java 运行环境的日志记录工具包，大量的 Java 框架包括 Elasticsearch 的最新版本都使用了该组件，故影响范围非常之大。

近日, 随着 Apache Log4j 的远程代码执行最新漏洞细节被公开，攻击者可通过构造恶意请求利用该漏洞实现在目标服务器上执行任意代码。可导致服务器被黑客控制，从而进行页面篡改、数据窃取、挖矿、勒索等行为。建议使用该组件的用户第一时间启动应急响应进行修复。

简单总结一下就是，在使用 Log4j 打印输出的日志中，如果发现日志内容中包含关键词 ${，那么这个里面包含的内容会当做变量来进行替换和执行，导致攻击者可以通过恶意构造日志内容来让 Java 进程来执行任意命令，达到攻击的效果。

【漏洞等级】：非常紧急

此次漏洞是用于 Log4j2 提供的 lookup 功能造成的，该功能允许开发者通过一些协议去读取相应环境中的配置。但在实现的过程中，并未对输入进行严格的判断，从而造成漏洞的发生。

【影响范围】：Java 类产品：Apache Log4j 2.x < 2.15.0-rc2，Elasticsearch 当前所有版本。

【攻击检测】

可以通过检查日志中是否存在 jndi:ldap://、jndi:rmi 等字符来发现可能的攻击行为。

处理办法

最简单的办法是通过修改 config/jvm.options，新增以下参数，重启集群所有节点即可。

 -Dlog4j2.formatMsgNoLookups=true

不过，如果集群规模较大，数据较多，业务不能中断，不能通过修改 Elasticsearch 配置、或者替换 Log4j 的最新 jar 包来重启集群的情况，可以考虑使用极限网关来进行拦截或者参数替换甚至是直接阻断请求。

通过在网关层对发往 Elasticsearch 的请求统一进行参数检测，将包含的敏感关键词 ${ 进行替换或者直接拒绝， 可以防止带攻击的请求到达 Elasticsearch 服务端而被 Log4j 打印相关日志的时候执行恶意攻击命令，从而避免被攻击。

极限网关是透明代理，只需要在应用端，将以往配置指向 Elasticsearch 的地址替换为现在网关的地址即可，其他都不用动。

参考配置

下载最新的 1.5.0-SNAPSHOT 版本http://release.elasticsearch.cn/gateway/snapshot/

使用极限网关的 context_filter 过滤器，对请求上下文 _ctx.request.to_string 进行关键字检测，过滤掉恶意流量，从而阻断攻击。

新增一个配置文件 gateway.yml

path.data: data
path.logs: log

entry:
  - name: es_entrypoint
    enabled: true
    router: default
    max_concurrency: 20000
    network:
      binding: 0.0.0.0:8000

router:
  - name: default
    default_flow: main_flow

flow:
  - name: main_flow
    filter:
      - context_filter:
          context: _ctx.request.to_string
          action: redirect_flow
          status: 403
          flow: log4j_matched_flow
          must_not: # any match will be filtered
            regex:
              - \$\{.*?\}
              - "%24%7B.*?%7D" #urlencode
            contain:
              - "jndi:"
              - "jndi:ldap:"
              - "jndi:rmi:"
              - "jndi%3A" #urlencode
              - "jndi%3Aldap%3A" #urlencode
              - "jndi%3Armi%3A" #urlencode
      - elasticsearch:
          elasticsearch: es-server
  - name: log4j_matched_flow
    filter:
      - echo:
          message: 'Apache Log4j 2, Boom!'

elasticsearch:
  - name: es-server
    enabled: true
    endpoints:
      - http://localhost:9200

启动网关：

➜  ./bin/gateway -config /tmp/gateway.yml
   ___   _   _____  __  __    __  _       
  / _ \ /_\ /__   \/__\/ / /\ \ \/_\ /\_/\
 / /_\///_\\  / /\/_\  \ \/  \/ //_\\\_ _/
/ /_\\/  _  \/ / //__   \  /\  /  _  \/ \ 
\____/\_/ \_/\/  \__/    \/  \/\_/ \_/\_/ 

[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.
[GATEWAY] 1.0.0_SNAPSHOT, 2021-12-10 23:55:34, 2212aff
[12-11 01:55:49] [INF] [app.go:250] initializing gateway.
[12-11 01:55:49] [INF] [instance.go:26] workspace: /Users/medcl/go/src/infini.sh/gateway/data/gateway/nodes/0
[12-11 01:55:49] [INF] [api.go:261] api listen at: http://0.0.0.0:2900
[12-11 01:55:49] [INF] [reverseproxy.go:253] elasticsearch [es-server] hosts: [] => [localhost:9200]
[12-11 01:55:49] [INF] [entry.go:296] entry [es_entrypoint] listen at: http://0.0.0.0:8000
[12-11 01:55:49] [INF] [module.go:116] all modules started
[12-11 01:55:49] [INF] [app.go:357] gateway is running now.
[12-11 01:55:49] [INF] [actions.go:236] elasticsearch [es-server] is available

将要使用的测试命令 ${java:os} 使用 urlencode 转码为 %24%7Bjava%3Aos%7D，构造查询语句，分别测试。

不走网关：

~%  curl 'http://localhost:9200/index1/_search?q=%24%7Bjava%3Aos%7D' 
{"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"}],"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"},"status":404}%

查看 Elasticsearch 端日志为：

[2021-12-11T01:49:50,303][DEBUG][r.suppressed             ] path: /index1/_search, params: {q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1}
org.elasticsearch.index.IndexNotFoundException: no such index
    at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.infe(IndexNameExpressionResolver.java:678) ~[elasticsearch-5.6.15.jar:5.6.15]
    at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.innerResolve(IndexNameExpressionResolver.java:632) ~[elasticsearch-5.6.15.jar:5.6.15]
    at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.resolve(IndexNameExpressionResolver.java:580) ~[elasticsearch-5.6.15.jar:5.6.15]

可以看到查询条件里面的 q=${java:os} 被执行了，变成了 q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1，说明变量被解析且执行，存在漏洞利用的风险。

那走网关之后呢：

~%  curl 'http://localhost:8000/index1/_search?q=%24%7Bjava%3Aos%7D' 

Apache Log4j 2, Boom!%

可以看到请求被过滤掉了，返回了自定义的信息。

还有一些其他测试命令，大家也可以试试：

#{java:vm}
~%  curl 'http://localhost:9200/index/_search?q=%24%7Bjava%3Avm%7D'
[2021-12-11T02:36:04,764][DEBUG][r.suppressed             ] [INFINI-2.local] path: /index/_search, params: {q=OpenJDK 64-Bit Server VM (build 25.72-b15, mixed mode), index=index}

~%  curl 'http://localhost:8000/index/_search?q=%24%7Bjava%3Avm%7D'
Apache Log4j 2, Boom!% 

#{jndi:rmi://localhost:1099/api}
~%  curl 'http://localhost:9200/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
2021-12-11 03:35:06,493 elasticsearch[YOmFJsW][search][T#3] ERROR An exception occurred processing Appender console java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object

~%  curl 'http://localhost:8000/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
Apache Log4j 2, Boom!%

另外不同版本的 Elasticsearch 对于攻击的复现程度参差不齐，因为 es 不同版本是否有 Java Security Manager 、不同版本 JDK 、以及默认配置也不相同，新一点的 es 其实同样可以触发恶意请求，只不过网络调用被默认的网络策略给拒绝了，相对安全，当然如果设置不当同样存在风险，见过很多用户一上来就关默认安全配置的，甚至还放开很多暂时用不上的权限，另外未知的攻击方式也一定有，比如大量日志产生的系统调用可能会拖垮机器造成服务不可用，所以要么还是尽快改配置换 log4j 包重启集群，或者走网关来过滤阻断请求吧。

使用极限网关处置类似安全事件的好处是，Elasticsearch 服务器不用做任何变动，尤其是大规模集群的场景，可以节省大量的工作，提升效率，非常灵活，缩短安全处置的时间，降低企业风险。

elasticsearch的安全插件配置http basic认证后，/_cat 页面会在保护范围内吗

Elasticsearch • user 回复了问题 • 2 人关注 • 1 个回复 • 2932 次浏览 • 2020-08-04 15:50 • 来自相关话题

es被攻击了，怎么处理?

Elasticsearch • zhangyang 回复了问题 • 8 人关注 • 5 个回复 • 11624 次浏览 • 2018-09-14 09:34 • 来自相关话题

说说ES安全，比如关键词包含 百度% 这样就会报错。我们应该这么做，避免这些错误

Elasticsearch • yayg2008 回复了问题 • 4 人关注 • 6 个回复 • 2957 次浏览 • 2018-04-23 10:55 • 来自相关话题

Elasticsearch 安全加固 101

Elasticsearch • medcl 发表了文章 • 8 个评论 • 22553 次浏览 • 2017-01-13 13:03 • 来自相关话题

images.jpeg
 最近 MongoDB 的安全事件闹得沸沸扬扬，应该不少人都听说了吧，事情大概是，因为 MongoDB 默认的安全设置造成了数据外泄并且被黑客勒索才能找回数据，想了解的，这里有几个链接： http://www.jianshu.com/p/48d17a69e190 http://mt.sohu.com/20170107/n478047698.shtml​  http://bbs.tianya.cn/post-itinfo-503786-1.shtml​    安全从来不是等到出事才要注意的事情，可以说安全是第一重要的事情，不管你是公司的CTO、技术总监、运维总监、架构师还是一线工程师，都应该有安全意识，好了，废话不多说了，Elasticsearch 的用户现在越来越多了，有些已经成为公司的基础服务，所以数据的安全非常重要，今天主要给大家介绍 Elasticsearch 围绕安全方面的的几点使用事项：   下载安装        请使用正规渠道下载 Elasticsearch，首选官方网站，下载完成，记得要验证下载文件的 sha1值和官网下载的提供的sha1值进行对比，避免下载过程中被人拦截破坏文件，甚至注入恶意代码。 不要随便安装第三方的插件，插件有可能引入安全漏洞甚至本身自带后门，需谨慎使用。     链接君：https://www.elastic.co/downloads      使用最新的 Elasticsearch       请关注 Elastic 网站，及时更新升级 Elasticsearch 的最新版本，Elasticsearch 每次版本发布都会优化和改进一部分功能，尤其是安全漏洞的补丁，仔细阅读 Elasticsearch 的更新记录，Elasticsearch 的版本遵照 语义化版本 ，所以小版本间应该是能够无缝升级的，建议及时本地测试和线上更新，升级前，记得 snapshot 做好备份。     链接君：https://www.elastic.co/downloads     修改默认的 Elasticsearch 集群名称        Elasticsearch 默认的集群名称是 elasticsearch，请在生成环境上一定要修改成其他的名称，并且不同的环境和不同的集群要保证不相同，监控集群节点情况，如果有未知节点加入，一定要及时预警。     文档君：https://www.elastic.co/guide/e ... .name    不要暴露 Elasticsearch 在公网上         Elasticsearch 默认端口是9200，绑定的是本机127.0.0.1的这个 ip，这个默认参数其实很安全，但是有很多人想要绑定其他的 lan 口或者公网的 ip，可以修改相应参数，记住，修改有风险，如果确实需要将 Elasticsearch 暴露在公网环境，请修改特定的端口绑定IP，不要直接修改参数： network.host，而是要分别修改：http.port 来绑定 HTTP 协议9200 端口的 IP（RESTful 接口调用），修改：transport.tcp.port 对应的 TCP 9300 端口的 IP（集群内通信），如果你不需要 http 端口，你干脆禁用掉，另外还需要在 Elasticsearch 之上加上成熟的安全防护措施（注意是成熟的！），在这里提供几种方案：
  1. 9200的 HTTP 接口之上加上 Nginx 来提供 Http Basic-Auth 的基本的身份认证，辅助 SSL 证书进行传输层的加密，Nginx 进一步限制可接受 Verb 请求类型及可被操作的索引前缀。
  2. 使用 Elastic 的 X-Pack 插件，同样提供了 Http Basic-Auth 和 SSL 传输层的加密，X-Pack 还能提供内外 Elasticsearch 集群节点间的流量加密，避免旁路攻击。
       文档君：https://www.elastic.co/guide/e ... tings    禁用批量删除索引   Elasticsearch 支持通过_all（全部）和通配符（*）来批量删除索引，在生产环境，这个有点危险，你可以通过设置： action.destructive_requires_name: true 来禁用它。 安全使用动态脚本      Elasticsearch 的脚本很方便的可以对数据进行操作，不过如果你暂时没有用上，还请禁用它（Elasticsearch 在1.2.x 以后已经默认禁用了），如果你已经在使用动态脚本，比如 Groovy，它不是沙盒机制的脚本引擎，启用 inline 或 store 类型的groovy 有安全风险，请限制脚本的接触方，比如通过模板的方式来限制脚本的调用，只需要执行特定预先定义好的脚本，对调用参数进行过滤和参数值的检测，做好验证，同时各种日志都必须要保留好，方便进行日志分析，异常的调用和请求一定要有发现和预警机制。       Elasticsearch 默认启用了  Java Security Manager ，但还请正确配置其白名单。       使用 Groovy 或者JavaScript 等脚本的用户，尽快迁移到 Painless 脚本，Painless 更快更安全。       文档君：https://www.elastic.co/guide/e ... .html   给 Elasticsearch 服务器加固        服务器加固是一个必备流程，不管上面运行的是什么服务；      首先，请开启防火墙，请设置防火墙规则，只开启必备的端口，完成之后，使用扫描工具扫描服务器，检查端口开发情况；      如果可能，不要用密码的方法来远程登录服务器，使用公私钥的方式来 ssh 登录服务器，如果只能使用密码，请妥善保管好你的用户名和密码，禁用 root 用户，不用使用弱密码。      关注 Java 最新的漏洞，使用安全的 JVM 运行时。      服务器及时更新最新的软件，使用安全的 repo 软件源，绑定软件源的 host和 ip，避免 dns 污染造成的攻击，关注服务器软件漏洞，及时打上补丁。      收集系统日志和安装相应的入侵检测软件，及时发现服务器是否有异常行为。   不要以 root 身份运行 Elasticsearch     如果你的运维人员打算以 root 身份来运行某个服务，这个运维人员一定是一个不合格的运维人员，记住一定不要以 root 身份来运行 Elasticsearch，另外，要不和其他的服务公用相同的用户，然后还要保证该用户的权限要最小化。      范例君：
sudo -u es-user ES_JAVA_OPTS="-Xms1024m -Xmx1024m"  /opt/elasticsearch/bin/elasticsearc
  正确设置 Elasticsearch 的数据目录        请确保 Elasticsearch 的目录分配了合理的读写权限，避免使用共享文件系统，确保只有 elasticsearch 的启动用户才能访问，同理，日志目录也一样需要正确配置，避免泄露敏感信息。      文档君：https://www.elastic.co/guide/e ... tings   定期对 Elasticsearch 进行备份        使用 Elasticsearch 提供的备份还原机制，定期对 Elasticsearch 的数据进行快照备份，以备不时之需。      文档君：https://www.elastic.co/guide/e ... .html   加上监控和预警        Elasticsearch 提供了很好的默认参数，对参数方面还做了正确性检测，bootstrap 启动检查，不准确的参数，直接不允许 Elasticsearch 启动，以至于有很多人抱怨，怎么现在部署到线上默认就需要做这么多设置才能使用呢，是的，以前启动就默认绑定了所有的网卡，集群见自动发现和相连，现在需要手动绑定局域网网卡，默认只是绑定的本机127.0.0.1的 ip，对上线来说麻烦了一点，做了这些检查也就是为了保证数据安全，以前很多的公网都能直接访问的 Elasticsearch 实例，都是因为默认设置就绑定了公网 ip，但是这些还不够，作为用户，你还需要收集各种日志和系统监控信息，及时主动掌握服务健康和资源使用情况，发现异常情况要及时处理，这里提供一些方案:
  1. 使用开源的 Elastic Stack 收集这些日志，可以使用 Filebeat 收集日志，Metricbeat收集系统监控信息，存进 Elasticsearch，一旦发现异常的波动，使用 Watcher 来进行预警，通过邮件或者 webhook 调用短信、微信或者电话。
  2. 使用其他厂商的安全监控产品。
  3. 使用托管的 Elasticsearch 云的产品，如 Elastic Cloud等等。
是的，把安全这个事情考虑进去之后，很多事情都要比没考虑要变得更加复杂和麻烦，千里之堤毁于蚁穴，一个不起眼的忽视就有可能造成全部数据的丢失和泄露，出来混迟早是要还的，安全问题千万不能忽视。   以上几点建议举例针对 linux 平台，其他平台思路基本上一样，仅供参考，安全是一个包含很多方方面面的学科，抛砖引玉，希望大家有用。  最后，Elastic 非常关心我们的产品安全，如果您发现有任何安全方面的问题，还请在这里上报： https://www.elastic.co/community/security 企业用户需要 X-Pack 及 Elastic 官方技术支持，请访问下面的链接： https://www.elastic.co/cn/contact

关于elasticserach安全问题

Elasticsearch • fishman 回复了问题 • 4 人关注 • 2 个回复 • 5721 次浏览 • 2016-09-12 12:19 • 来自相关话题

更多...
条新动态, 点击查看
tonylxc

tonylxc 回答了问题 • 2015-03-15 17:20 • 5 个回复 不感兴趣

es被攻击了，怎么处理?

赞同来自:

1. 永远不要把Elasticsearch端口暴露给外网. Elasticsearch应当运行在private network中.
2. 禁用dynamic scripting.
3. Elasticsearch更新频繁, 务必跟上更新脚步至1.4.4
4. ... 显示全部 »
1. 永远不要把Elasticsearch端口暴露给外网. Elasticsearch应当运行在private network中.
2. 禁用dynamic scripting.
3. Elasticsearch更新频繁, 务必跟上更新脚步至1.4.4
4. Elasticsearch并不依赖于Shield插件. Shield插件只是一个extra sugar, 并且是商业收费.
3 0 收藏 分享
更多...

使用极限网关来处置 Elasticsearch 的 Apache Log4j 漏洞

Elasticsearch • medcl 发表了文章 • 2 个评论 • 6712 次浏览 • 2021-12-11 03:57 • 来自相关话题

昨日爆出的 Log4j 安全漏洞，业界一片哗然，今天给大家介绍一下，如何使用极限网关来快速处置 Elasticsearch 的 Apache Log4j 漏洞。

【CVE 地址】

https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

【漏洞描述】

Apache Log4j 是一款非常流行的开源的用于 Java 运行环境的日志记录工具包，大量的 Java 框架包括 Elasticsearch 的最新版本都使用了该组件，故影响范围非常之大。

近日, 随着 Apache Log4j 的远程代码执行最新漏洞细节被公开，攻击者可通过构造恶意请求利用该漏洞实现在目标服务器上执行任意代码。可导致服务器被黑客控制，从而进行页面篡改、数据窃取、挖矿、勒索等行为。建议使用该组件的用户第一时间启动应急响应进行修复。

简单总结一下就是，在使用 Log4j 打印输出的日志中，如果发现日志内容中包含关键词 ${，那么这个里面包含的内容会当做变量来进行替换和执行，导致攻击者可以通过恶意构造日志内容来让 Java 进程来执行任意命令，达到攻击的效果。

【漏洞等级】：非常紧急

此次漏洞是用于 Log4j2 提供的 lookup 功能造成的，该功能允许开发者通过一些协议去读取相应环境中的配置。但在实现的过程中，并未对输入进行严格的判断，从而造成漏洞的发生。

【影响范围】：Java 类产品：Apache Log4j 2.x < 2.15.0-rc2，Elasticsearch 当前所有版本。

【攻击检测】

可以通过检查日志中是否存在 jndi:ldap://、jndi:rmi 等字符来发现可能的攻击行为。

处理办法

最简单的办法是通过修改 config/jvm.options，新增以下参数，重启集群所有节点即可。

 -Dlog4j2.formatMsgNoLookups=true

不过，如果集群规模较大，数据较多，业务不能中断，不能通过修改 Elasticsearch 配置、或者替换 Log4j 的最新 jar 包来重启集群的情况，可以考虑使用极限网关来进行拦截或者参数替换甚至是直接阻断请求。

通过在网关层对发往 Elasticsearch 的请求统一进行参数检测，将包含的敏感关键词 ${ 进行替换或者直接拒绝， 可以防止带攻击的请求到达 Elasticsearch 服务端而被 Log4j 打印相关日志的时候执行恶意攻击命令，从而避免被攻击。

极限网关是透明代理，只需要在应用端，将以往配置指向 Elasticsearch 的地址替换为现在网关的地址即可，其他都不用动。

参考配置

下载最新的 1.5.0-SNAPSHOT 版本http://release.elasticsearch.cn/gateway/snapshot/

使用极限网关的 context_filter 过滤器，对请求上下文 _ctx.request.to_string 进行关键字检测，过滤掉恶意流量，从而阻断攻击。

新增一个配置文件 gateway.yml

path.data: data
path.logs: log

entry:
  - name: es_entrypoint
    enabled: true
    router: default
    max_concurrency: 20000
    network:
      binding: 0.0.0.0:8000

router:
  - name: default
    default_flow: main_flow

flow:
  - name: main_flow
    filter:
      - context_filter:
          context: _ctx.request.to_string
          action: redirect_flow
          status: 403
          flow: log4j_matched_flow
          must_not: # any match will be filtered
            regex:
              - \$\{.*?\}
              - "%24%7B.*?%7D" #urlencode
            contain:
              - "jndi:"
              - "jndi:ldap:"
              - "jndi:rmi:"
              - "jndi%3A" #urlencode
              - "jndi%3Aldap%3A" #urlencode
              - "jndi%3Armi%3A" #urlencode
      - elasticsearch:
          elasticsearch: es-server
  - name: log4j_matched_flow
    filter:
      - echo:
          message: 'Apache Log4j 2, Boom!'

elasticsearch:
  - name: es-server
    enabled: true
    endpoints:
      - http://localhost:9200

启动网关：

➜  ./bin/gateway -config /tmp/gateway.yml
   ___   _   _____  __  __    __  _       
  / _ \ /_\ /__   \/__\/ / /\ \ \/_\ /\_/\
 / /_\///_\\  / /\/_\  \ \/  \/ //_\\\_ _/
/ /_\\/  _  \/ / //__   \  /\  /  _  \/ \ 
\____/\_/ \_/\/  \__/    \/  \/\_/ \_/\_/ 

[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.
[GATEWAY] 1.0.0_SNAPSHOT, 2021-12-10 23:55:34, 2212aff
[12-11 01:55:49] [INF] [app.go:250] initializing gateway.
[12-11 01:55:49] [INF] [instance.go:26] workspace: /Users/medcl/go/src/infini.sh/gateway/data/gateway/nodes/0
[12-11 01:55:49] [INF] [api.go:261] api listen at: http://0.0.0.0:2900
[12-11 01:55:49] [INF] [reverseproxy.go:253] elasticsearch [es-server] hosts: [] => [localhost:9200]
[12-11 01:55:49] [INF] [entry.go:296] entry [es_entrypoint] listen at: http://0.0.0.0:8000
[12-11 01:55:49] [INF] [module.go:116] all modules started
[12-11 01:55:49] [INF] [app.go:357] gateway is running now.
[12-11 01:55:49] [INF] [actions.go:236] elasticsearch [es-server] is available

将要使用的测试命令 ${java:os} 使用 urlencode 转码为 %24%7Bjava%3Aos%7D，构造查询语句，分别测试。

不走网关：

~%  curl 'http://localhost:9200/index1/_search?q=%24%7Bjava%3Aos%7D' 
{"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"}],"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"},"status":404}%

查看 Elasticsearch 端日志为：

[2021-12-11T01:49:50,303][DEBUG][r.suppressed             ] path: /index1/_search, params: {q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1}
org.elasticsearch.index.IndexNotFoundException: no such index
    at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.infe(IndexNameExpressionResolver.java:678) ~[elasticsearch-5.6.15.jar:5.6.15]
    at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.innerResolve(IndexNameExpressionResolver.java:632) ~[elasticsearch-5.6.15.jar:5.6.15]
    at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.resolve(IndexNameExpressionResolver.java:580) ~[elasticsearch-5.6.15.jar:5.6.15]

可以看到查询条件里面的 q=${java:os} 被执行了，变成了 q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1，说明变量被解析且执行，存在漏洞利用的风险。

那走网关之后呢：

~%  curl 'http://localhost:8000/index1/_search?q=%24%7Bjava%3Aos%7D' 

Apache Log4j 2, Boom!%

可以看到请求被过滤掉了，返回了自定义的信息。

还有一些其他测试命令，大家也可以试试：

#{java:vm}
~%  curl 'http://localhost:9200/index/_search?q=%24%7Bjava%3Avm%7D'
[2021-12-11T02:36:04,764][DEBUG][r.suppressed             ] [INFINI-2.local] path: /index/_search, params: {q=OpenJDK 64-Bit Server VM (build 25.72-b15, mixed mode), index=index}

~%  curl 'http://localhost:8000/index/_search?q=%24%7Bjava%3Avm%7D'
Apache Log4j 2, Boom!% 

#{jndi:rmi://localhost:1099/api}
~%  curl 'http://localhost:9200/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
2021-12-11 03:35:06,493 elasticsearch[YOmFJsW][search][T#3] ERROR An exception occurred processing Appender console java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object

~%  curl 'http://localhost:8000/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
Apache Log4j 2, Boom!%

另外不同版本的 Elasticsearch 对于攻击的复现程度参差不齐，因为 es 不同版本是否有 Java Security Manager 、不同版本 JDK 、以及默认配置也不相同，新一点的 es 其实同样可以触发恶意请求，只不过网络调用被默认的网络策略给拒绝了，相对安全，当然如果设置不当同样存在风险，见过很多用户一上来就关默认安全配置的，甚至还放开很多暂时用不上的权限，另外未知的攻击方式也一定有，比如大量日志产生的系统调用可能会拖垮机器造成服务不可用，所以要么还是尽快改配置换 log4j 包重启集群，或者走网关来过滤阻断请求吧。

使用极限网关处置类似安全事件的好处是，Elasticsearch 服务器不用做任何变动，尤其是大规模集群的场景，可以节省大量的工作，提升效率，非常灵活，缩短安全处置的时间，降低企业风险。

Elasticsearch 安全加固 101

Elasticsearch • medcl 发表了文章 • 8 个评论 • 22553 次浏览 • 2017-01-13 13:03 • 来自相关话题

images.jpeg
 最近 MongoDB 的安全事件闹得沸沸扬扬，应该不少人都听说了吧，事情大概是，因为 MongoDB 默认的安全设置造成了数据外泄并且被黑客勒索才能找回数据，想了解的，这里有几个链接： http://www.jianshu.com/p/48d17a69e190 http://mt.sohu.com/20170107/n478047698.shtml​  http://bbs.tianya.cn/post-itinfo-503786-1.shtml​    安全从来不是等到出事才要注意的事情，可以说安全是第一重要的事情，不管你是公司的CTO、技术总监、运维总监、架构师还是一线工程师，都应该有安全意识，好了，废话不多说了，Elasticsearch 的用户现在越来越多了，有些已经成为公司的基础服务，所以数据的安全非常重要，今天主要给大家介绍 Elasticsearch 围绕安全方面的的几点使用事项：   下载安装        请使用正规渠道下载 Elasticsearch，首选官方网站，下载完成，记得要验证下载文件的 sha1值和官网下载的提供的sha1值进行对比，避免下载过程中被人拦截破坏文件，甚至注入恶意代码。 不要随便安装第三方的插件，插件有可能引入安全漏洞甚至本身自带后门，需谨慎使用。     链接君：https://www.elastic.co/downloads      使用最新的 Elasticsearch       请关注 Elastic 网站，及时更新升级 Elasticsearch 的最新版本，Elasticsearch 每次版本发布都会优化和改进一部分功能，尤其是安全漏洞的补丁，仔细阅读 Elasticsearch 的更新记录，Elasticsearch 的版本遵照 语义化版本 ，所以小版本间应该是能够无缝升级的，建议及时本地测试和线上更新，升级前，记得 snapshot 做好备份。     链接君：https://www.elastic.co/downloads     修改默认的 Elasticsearch 集群名称        Elasticsearch 默认的集群名称是 elasticsearch，请在生成环境上一定要修改成其他的名称，并且不同的环境和不同的集群要保证不相同，监控集群节点情况，如果有未知节点加入，一定要及时预警。     文档君：https://www.elastic.co/guide/e ... .name    不要暴露 Elasticsearch 在公网上         Elasticsearch 默认端口是9200，绑定的是本机127.0.0.1的这个 ip，这个默认参数其实很安全，但是有很多人想要绑定其他的 lan 口或者公网的 ip，可以修改相应参数，记住，修改有风险，如果确实需要将 Elasticsearch 暴露在公网环境，请修改特定的端口绑定IP，不要直接修改参数： network.host，而是要分别修改：http.port 来绑定 HTTP 协议9200 端口的 IP（RESTful 接口调用），修改：transport.tcp.port 对应的 TCP 9300 端口的 IP（集群内通信），如果你不需要 http 端口，你干脆禁用掉，另外还需要在 Elasticsearch 之上加上成熟的安全防护措施（注意是成熟的！），在这里提供几种方案：
  1. 9200的 HTTP 接口之上加上 Nginx 来提供 Http Basic-Auth 的基本的身份认证，辅助 SSL 证书进行传输层的加密，Nginx 进一步限制可接受 Verb 请求类型及可被操作的索引前缀。
  2. 使用 Elastic 的 X-Pack 插件，同样提供了 Http Basic-Auth 和 SSL 传输层的加密，X-Pack 还能提供内外 Elasticsearch 集群节点间的流量加密，避免旁路攻击。
       文档君：https://www.elastic.co/guide/e ... tings    禁用批量删除索引   Elasticsearch 支持通过_all（全部）和通配符（*）来批量删除索引，在生产环境，这个有点危险，你可以通过设置： action.destructive_requires_name: true 来禁用它。 安全使用动态脚本      Elasticsearch 的脚本很方便的可以对数据进行操作，不过如果你暂时没有用上，还请禁用它（Elasticsearch 在1.2.x 以后已经默认禁用了），如果你已经在使用动态脚本，比如 Groovy，它不是沙盒机制的脚本引擎，启用 inline 或 store 类型的groovy 有安全风险，请限制脚本的接触方，比如通过模板的方式来限制脚本的调用，只需要执行特定预先定义好的脚本，对调用参数进行过滤和参数值的检测，做好验证，同时各种日志都必须要保留好，方便进行日志分析，异常的调用和请求一定要有发现和预警机制。       Elasticsearch 默认启用了  Java Security Manager ，但还请正确配置其白名单。       使用 Groovy 或者JavaScript 等脚本的用户，尽快迁移到 Painless 脚本，Painless 更快更安全。       文档君：https://www.elastic.co/guide/e ... .html   给 Elasticsearch 服务器加固        服务器加固是一个必备流程，不管上面运行的是什么服务；      首先，请开启防火墙，请设置防火墙规则，只开启必备的端口，完成之后，使用扫描工具扫描服务器，检查端口开发情况；      如果可能，不要用密码的方法来远程登录服务器，使用公私钥的方式来 ssh 登录服务器，如果只能使用密码，请妥善保管好你的用户名和密码，禁用 root 用户，不用使用弱密码。      关注 Java 最新的漏洞，使用安全的 JVM 运行时。      服务器及时更新最新的软件，使用安全的 repo 软件源，绑定软件源的 host和 ip，避免 dns 污染造成的攻击，关注服务器软件漏洞，及时打上补丁。      收集系统日志和安装相应的入侵检测软件，及时发现服务器是否有异常行为。   不要以 root 身份运行 Elasticsearch     如果你的运维人员打算以 root 身份来运行某个服务，这个运维人员一定是一个不合格的运维人员，记住一定不要以 root 身份来运行 Elasticsearch，另外，要不和其他的服务公用相同的用户，然后还要保证该用户的权限要最小化。      范例君：
sudo -u es-user ES_JAVA_OPTS="-Xms1024m -Xmx1024m"  /opt/elasticsearch/bin/elasticsearc
  正确设置 Elasticsearch 的数据目录        请确保 Elasticsearch 的目录分配了合理的读写权限，避免使用共享文件系统，确保只有 elasticsearch 的启动用户才能访问，同理，日志目录也一样需要正确配置，避免泄露敏感信息。      文档君：https://www.elastic.co/guide/e ... tings   定期对 Elasticsearch 进行备份        使用 Elasticsearch 提供的备份还原机制，定期对 Elasticsearch 的数据进行快照备份，以备不时之需。      文档君：https://www.elastic.co/guide/e ... .html   加上监控和预警        Elasticsearch 提供了很好的默认参数，对参数方面还做了正确性检测，bootstrap 启动检查，不准确的参数，直接不允许 Elasticsearch 启动，以至于有很多人抱怨，怎么现在部署到线上默认就需要做这么多设置才能使用呢，是的，以前启动就默认绑定了所有的网卡，集群见自动发现和相连，现在需要手动绑定局域网网卡，默认只是绑定的本机127.0.0.1的 ip，对上线来说麻烦了一点，做了这些检查也就是为了保证数据安全，以前很多的公网都能直接访问的 Elasticsearch 实例，都是因为默认设置就绑定了公网 ip，但是这些还不够，作为用户，你还需要收集各种日志和系统监控信息，及时主动掌握服务健康和资源使用情况，发现异常情况要及时处理，这里提供一些方案:
  1. 使用开源的 Elastic Stack 收集这些日志，可以使用 Filebeat 收集日志，Metricbeat收集系统监控信息，存进 Elasticsearch，一旦发现异常的波动，使用 Watcher 来进行预警，通过邮件或者 webhook 调用短信、微信或者电话。
  2. 使用其他厂商的安全监控产品。
  3. 使用托管的 Elasticsearch 云的产品，如 Elastic Cloud等等。
是的，把安全这个事情考虑进去之后，很多事情都要比没考虑要变得更加复杂和麻烦，千里之堤毁于蚁穴，一个不起眼的忽视就有可能造成全部数据的丢失和泄露，出来混迟早是要还的，安全问题千万不能忽视。   以上几点建议举例针对 linux 平台，其他平台思路基本上一样，仅供参考，安全是一个包含很多方方面面的学科，抛砖引玉，希望大家有用。  最后，Elastic 非常关心我们的产品安全，如果您发现有任何安全方面的问题，还请在这里上报： https://www.elastic.co/community/security 企业用户需要 X-Pack 及 Elastic 官方技术支持，请访问下面的链接： https://www.elastic.co/cn/contact
更多...

elasticsearch的安全插件配置http basic认证后，/_cat 页面会在保护范围内吗

回复

Elasticsearch • user 回复了问题 • 2 人关注 • 1 个回复 • 2932 次浏览 • 2020-08-04 15:50 • 来自相关话题

es被攻击了，怎么处理?

回复

Elasticsearch • zhangyang 回复了问题 • 8 人关注 • 5 个回复 • 11624 次浏览 • 2018-09-14 09:34 • 来自相关话题

说说ES安全，比如关键词包含 百度% 这样就会报错。我们应该这么做，避免这些错误

回复

Elasticsearch • yayg2008 回复了问题 • 4 人关注 • 6 个回复 • 2957 次浏览 • 2018-04-23 10:55 • 来自相关话题

关于elasticserach安全问题

回复

Elasticsearch • fishman 回复了问题 • 4 人关注 • 2 个回复 • 5721 次浏览 • 2016-09-12 12:19 • 来自相关话题

更多...

开启安全功能 ES 集群就安全了吗？

Easysearch • yangmf2040 发表了文章 • 0 个评论 • 3870 次浏览 • 2023-12-27 10:38 • 来自相关话题

背景

经常跟 ES 打交道的朋友都知道，现在主流的 ES 集群安全方案是：RBAC + TLS for Internal + HTTPS 。

作为终端用户一般只需要关心用户名和密码就行了。作为管理和运维 ES 的人员来说，可能希望 ES 能提供密码策略来强制密码强度和密码使用周期。遗憾的是 ES 对密码强度和密码使用周期没有任何强制要求。如果不注意，可能我们天天都在使用“弱密码”或从不修改的密码（直到无法登录）。而且 ES 对连续的认证失败，不会做任何处理，这让 ES 很容易遭受暴力破解的入侵。

那还有没有别的办法，进一步提高安全呢？ 其实，网关可以来帮忙。

虽然网关无法强制提高密码复杂度，但可以提高 ES 集群被暴力破解的难度。

大家都知道，暴力破解--本质就是不停的“猜”你的密码。以现在的 CPU 算力，一秒钟“猜”个几千上万次不过是洒洒水，而且 CPU 监控都不带波动的，很难发现异常。从这里入手，一方面，网关可以延长认证失败的过程--延迟返回结果，让破解不再暴力。另一方面，网关可以记录认证失败的情况，做到实时监控，有条件的告警。一旦出现苗头，可以使用网关阻断该 IP 或用户发来的任何请求。

场景模拟

首先，用网关代理 ES 集群，并在 default_flow 中增加一段 response_status_filter 过滤器配置，对返回码是 401 的请求，跳转到 rate_limit_flow 进行降速，延迟 5 秒返回。

  - name: default_flow
    filter:
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
      - response_status_filter:
          exclude:
            - 401
          action: redirect_flow
          flow: rate_limit_flow
  - name: rate_limit_flow
    filter:
      - sleep:
          sleep_in_million_seconds: 5000

其次，对于失败的认证，我们可以通过 Console 来做个看板实时分析，展示。

折线图、饼图图、柱状图等，多种展示方式，大家可充分发挥。

最后，可在 Console 的告警中心，配置对应的告警规则，实时监控该类事件，方便及时跟进处置。

效果测试

先带上正确的用户名密码测试，看看返回速度。

0.011 秒返回。再使用错误的密码测试。

整整 5 秒多后，才回返结果。如果要暴力破解，每 5 秒钟甚至更久才尝试一个密码，这还叫暴力吗？

看板示例

此处仅仅是抛砖引玉，欢迎大家发挥想象。

告警示例

建立告警规则，用户 1 分钟内超过 3 次登录失败，就产生告警。

可在告警中心查看详情，也可将告警推送至微信、钉钉、飞书、邮件等。

查看告警详情，是 es 用户触发了告警。

最后，剩下的工作就是对该账号的处置了。如果有需要可以考虑阻止该用户或 IP 的请求，对应的过滤器文档在这里，老规矩加到 default_flow 里就行了。

如果小伙伴有其他办法提升 ES 集群安全，欢迎和我们一起讨论、交流。我们的宗旨是：让搜索更简单！

【警惕】Grafana 0day 高危漏洞已爆出，尽快处理

资讯动态 • medcl 发表了文章 • 0 个评论 • 2517 次浏览 • 2021-12-14 10:11 • 来自相关话题

来源：https://www.freebuf.com/vuls/307891.html   一、漏洞概况 Grafana是一个跨平台的开源的度量分析和可视化工具，可以通过将采集的数据查询然后可视化的展示，并及时通知。它主要有以下六大特点： 1、展示方式：快速灵活的客户端图表，面板插件有许多不同方式的可视化指标和日志，官方库中具有丰富的仪表盘插件，比如热图、折线图、图表等多种展示方式； 2、数据源：Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch和KairosDB等； 3、通知提醒：以可视方式定义最重要指标的警报规则，Grafana将不断计算并发送通知，在数据达到阈值时通过Slack、PagerDuty等获得通知； 4、混合展示：在同一图表中混合使用不同的数据源，可以基于每个查询指定数据源，甚至自定义数据源； 5、注释：使用来自不同数据源的丰富事件注释图表，将鼠标悬停在事件上会显示完整的事件元数据和标记； 6、过滤器：Ad-hoc过滤器允许动态创建新的键/值过滤器，这些过滤器会自动应用于使用该数据源的所有查询。 二、漏洞分析 此次受影响的版本如下： Grafana 是否受影响 8.x 是 漏洞由grafana-main\pkg\api\api.go引起
1639011455_61b1547fd88db6e6a34c4.png
分析原因： api功能可以实现加载插件文件，然后返回文件内容 由于加载路径时候未进行过滤，导致../实现任意文件读取。
1639011486_61b1549e779dae64bdd3a.png
最后返回文件内容：
1639011521_61b154c188615e1b0dd3f.png
二、漏洞利用 GET /public/plugins/welcome/../../../../../../../../etc/passwd HTTP/1.1 Host: 127.0.0.1:3000 Content-Length: 21 Connection: close
1639011659_61b1554bb48bb99945d6f.png
三、漏洞评估 公开程度：已出现在野利用 利用条件：无权限要求 交互要求：0 click 漏洞危害：高危、任意文件读取 影响范围：Grafana 8.x 四、修复方案   1、目前厂商暂未修复，建议对../以及相关编码进行过滤。 2、上waf 3、加反向代理利用中间件对路径做normalize操作。

使用极限网关来处置 Elasticsearch 的 Apache Log4j 漏洞

Elasticsearch • medcl 发表了文章 • 2 个评论 • 6712 次浏览 • 2021-12-11 03:57 • 来自相关话题

昨日爆出的 Log4j 安全漏洞，业界一片哗然，今天给大家介绍一下，如何使用极限网关来快速处置 Elasticsearch 的 Apache Log4j 漏洞。

【CVE 地址】

https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

【漏洞描述】

Apache Log4j 是一款非常流行的开源的用于 Java 运行环境的日志记录工具包，大量的 Java 框架包括 Elasticsearch 的最新版本都使用了该组件，故影响范围非常之大。

近日, 随着 Apache Log4j 的远程代码执行最新漏洞细节被公开，攻击者可通过构造恶意请求利用该漏洞实现在目标服务器上执行任意代码。可导致服务器被黑客控制，从而进行页面篡改、数据窃取、挖矿、勒索等行为。建议使用该组件的用户第一时间启动应急响应进行修复。

简单总结一下就是，在使用 Log4j 打印输出的日志中，如果发现日志内容中包含关键词 ${，那么这个里面包含的内容会当做变量来进行替换和执行，导致攻击者可以通过恶意构造日志内容来让 Java 进程来执行任意命令，达到攻击的效果。

【漏洞等级】：非常紧急

此次漏洞是用于 Log4j2 提供的 lookup 功能造成的，该功能允许开发者通过一些协议去读取相应环境中的配置。但在实现的过程中，并未对输入进行严格的判断，从而造成漏洞的发生。

【影响范围】：Java 类产品：Apache Log4j 2.x < 2.15.0-rc2，Elasticsearch 当前所有版本。

【攻击检测】

可以通过检查日志中是否存在 jndi:ldap://、jndi:rmi 等字符来发现可能的攻击行为。

处理办法

最简单的办法是通过修改 config/jvm.options，新增以下参数，重启集群所有节点即可。

 -Dlog4j2.formatMsgNoLookups=true

不过，如果集群规模较大，数据较多，业务不能中断，不能通过修改 Elasticsearch 配置、或者替换 Log4j 的最新 jar 包来重启集群的情况，可以考虑使用极限网关来进行拦截或者参数替换甚至是直接阻断请求。

通过在网关层对发往 Elasticsearch 的请求统一进行参数检测，将包含的敏感关键词 ${ 进行替换或者直接拒绝， 可以防止带攻击的请求到达 Elasticsearch 服务端而被 Log4j 打印相关日志的时候执行恶意攻击命令，从而避免被攻击。

极限网关是透明代理，只需要在应用端，将以往配置指向 Elasticsearch 的地址替换为现在网关的地址即可，其他都不用动。

参考配置

下载最新的 1.5.0-SNAPSHOT 版本http://release.elasticsearch.cn/gateway/snapshot/

使用极限网关的 context_filter 过滤器，对请求上下文 _ctx.request.to_string 进行关键字检测，过滤掉恶意流量，从而阻断攻击。

新增一个配置文件 gateway.yml

path.data: data
path.logs: log

entry:
  - name: es_entrypoint
    enabled: true
    router: default
    max_concurrency: 20000
    network:
      binding: 0.0.0.0:8000

router:
  - name: default
    default_flow: main_flow

flow:
  - name: main_flow
    filter:
      - context_filter:
          context: _ctx.request.to_string
          action: redirect_flow
          status: 403
          flow: log4j_matched_flow
          must_not: # any match will be filtered
            regex:
              - \$\{.*?\}
              - "%24%7B.*?%7D" #urlencode
            contain:
              - "jndi:"
              - "jndi:ldap:"
              - "jndi:rmi:"
              - "jndi%3A" #urlencode
              - "jndi%3Aldap%3A" #urlencode
              - "jndi%3Armi%3A" #urlencode
      - elasticsearch:
          elasticsearch: es-server
  - name: log4j_matched_flow
    filter:
      - echo:
          message: 'Apache Log4j 2, Boom!'

elasticsearch:
  - name: es-server
    enabled: true
    endpoints:
      - http://localhost:9200

启动网关：

➜  ./bin/gateway -config /tmp/gateway.yml
   ___   _   _____  __  __    __  _       
  / _ \ /_\ /__   \/__\/ / /\ \ \/_\ /\_/\
 / /_\///_\\  / /\/_\  \ \/  \/ //_\\\_ _/
/ /_\\/  _  \/ / //__   \  /\  /  _  \/ \ 
\____/\_/ \_/\/  \__/    \/  \/\_/ \_/\_/ 

[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.
[GATEWAY] 1.0.0_SNAPSHOT, 2021-12-10 23:55:34, 2212aff
[12-11 01:55:49] [INF] [app.go:250] initializing gateway.
[12-11 01:55:49] [INF] [instance.go:26] workspace: /Users/medcl/go/src/infini.sh/gateway/data/gateway/nodes/0
[12-11 01:55:49] [INF] [api.go:261] api listen at: http://0.0.0.0:2900
[12-11 01:55:49] [INF] [reverseproxy.go:253] elasticsearch [es-server] hosts: [] => [localhost:9200]
[12-11 01:55:49] [INF] [entry.go:296] entry [es_entrypoint] listen at: http://0.0.0.0:8000
[12-11 01:55:49] [INF] [module.go:116] all modules started
[12-11 01:55:49] [INF] [app.go:357] gateway is running now.
[12-11 01:55:49] [INF] [actions.go:236] elasticsearch [es-server] is available

将要使用的测试命令 ${java:os} 使用 urlencode 转码为 %24%7Bjava%3Aos%7D，构造查询语句，分别测试。

不走网关：

~%  curl 'http://localhost:9200/index1/_search?q=%24%7Bjava%3Aos%7D' 
{"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"}],"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"},"status":404}%

查看 Elasticsearch 端日志为：

[2021-12-11T01:49:50,303][DEBUG][r.suppressed             ] path: /index1/_search, params: {q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1}
org.elasticsearch.index.IndexNotFoundException: no such index
    at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.infe(IndexNameExpressionResolver.java:678) ~[elasticsearch-5.6.15.jar:5.6.15]
    at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.innerResolve(IndexNameExpressionResolver.java:632) ~[elasticsearch-5.6.15.jar:5.6.15]
    at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.resolve(IndexNameExpressionResolver.java:580) ~[elasticsearch-5.6.15.jar:5.6.15]

可以看到查询条件里面的 q=${java:os} 被执行了，变成了 q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1，说明变量被解析且执行，存在漏洞利用的风险。

那走网关之后呢：

~%  curl 'http://localhost:8000/index1/_search?q=%24%7Bjava%3Aos%7D' 

Apache Log4j 2, Boom!%

可以看到请求被过滤掉了，返回了自定义的信息。

还有一些其他测试命令，大家也可以试试：

#{java:vm}
~%  curl 'http://localhost:9200/index/_search?q=%24%7Bjava%3Avm%7D'
[2021-12-11T02:36:04,764][DEBUG][r.suppressed             ] [INFINI-2.local] path: /index/_search, params: {q=OpenJDK 64-Bit Server VM (build 25.72-b15, mixed mode), index=index}

~%  curl 'http://localhost:8000/index/_search?q=%24%7Bjava%3Avm%7D'
Apache Log4j 2, Boom!% 

#{jndi:rmi://localhost:1099/api}
~%  curl 'http://localhost:9200/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
2021-12-11 03:35:06,493 elasticsearch[YOmFJsW][search][T#3] ERROR An exception occurred processing Appender console java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object

~%  curl 'http://localhost:8000/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
Apache Log4j 2, Boom!%

另外不同版本的 Elasticsearch 对于攻击的复现程度参差不齐，因为 es 不同版本是否有 Java Security Manager 、不同版本 JDK 、以及默认配置也不相同，新一点的 es 其实同样可以触发恶意请求，只不过网络调用被默认的网络策略给拒绝了，相对安全，当然如果设置不当同样存在风险，见过很多用户一上来就关默认安全配置的，甚至还放开很多暂时用不上的权限，另外未知的攻击方式也一定有，比如大量日志产生的系统调用可能会拖垮机器造成服务不可用，所以要么还是尽快改配置换 log4j 包重启集群，或者走网关来过滤阻断请求吧。

使用极限网关处置类似安全事件的好处是，Elasticsearch 服务器不用做任何变动，尤其是大规模集群的场景，可以节省大量的工作，提升效率，非常灵活，缩短安全处置的时间，降低企业风险。

Elasticsearch 安全加固 101

Elasticsearch • medcl 发表了文章 • 8 个评论 • 22553 次浏览 • 2017-01-13 13:03 • 来自相关话题

images.jpeg
 最近 MongoDB 的安全事件闹得沸沸扬扬，应该不少人都听说了吧，事情大概是，因为 MongoDB 默认的安全设置造成了数据外泄并且被黑客勒索才能找回数据，想了解的，这里有几个链接： http://www.jianshu.com/p/48d17a69e190 http://mt.sohu.com/20170107/n478047698.shtml​  http://bbs.tianya.cn/post-itinfo-503786-1.shtml​    安全从来不是等到出事才要注意的事情，可以说安全是第一重要的事情，不管你是公司的CTO、技术总监、运维总监、架构师还是一线工程师，都应该有安全意识，好了，废话不多说了，Elasticsearch 的用户现在越来越多了，有些已经成为公司的基础服务，所以数据的安全非常重要，今天主要给大家介绍 Elasticsearch 围绕安全方面的的几点使用事项：   下载安装        请使用正规渠道下载 Elasticsearch，首选官方网站，下载完成，记得要验证下载文件的 sha1值和官网下载的提供的sha1值进行对比，避免下载过程中被人拦截破坏文件，甚至注入恶意代码。 不要随便安装第三方的插件，插件有可能引入安全漏洞甚至本身自带后门，需谨慎使用。     链接君：https://www.elastic.co/downloads      使用最新的 Elasticsearch       请关注 Elastic 网站，及时更新升级 Elasticsearch 的最新版本，Elasticsearch 每次版本发布都会优化和改进一部分功能，尤其是安全漏洞的补丁，仔细阅读 Elasticsearch 的更新记录，Elasticsearch 的版本遵照 语义化版本 ，所以小版本间应该是能够无缝升级的，建议及时本地测试和线上更新，升级前，记得 snapshot 做好备份。     链接君：https://www.elastic.co/downloads     修改默认的 Elasticsearch 集群名称        Elasticsearch 默认的集群名称是 elasticsearch，请在生成环境上一定要修改成其他的名称，并且不同的环境和不同的集群要保证不相同，监控集群节点情况，如果有未知节点加入，一定要及时预警。     文档君：https://www.elastic.co/guide/e ... .name    不要暴露 Elasticsearch 在公网上         Elasticsearch 默认端口是9200，绑定的是本机127.0.0.1的这个 ip，这个默认参数其实很安全，但是有很多人想要绑定其他的 lan 口或者公网的 ip，可以修改相应参数，记住，修改有风险，如果确实需要将 Elasticsearch 暴露在公网环境，请修改特定的端口绑定IP，不要直接修改参数： network.host，而是要分别修改：http.port 来绑定 HTTP 协议9200 端口的 IP（RESTful 接口调用），修改：transport.tcp.port 对应的 TCP 9300 端口的 IP（集群内通信），如果你不需要 http 端口，你干脆禁用掉，另外还需要在 Elasticsearch 之上加上成熟的安全防护措施（注意是成熟的！），在这里提供几种方案：
  1. 9200的 HTTP 接口之上加上 Nginx 来提供 Http Basic-Auth 的基本的身份认证，辅助 SSL 证书进行传输层的加密，Nginx 进一步限制可接受 Verb 请求类型及可被操作的索引前缀。
  2. 使用 Elastic 的 X-Pack 插件，同样提供了 Http Basic-Auth 和 SSL 传输层的加密，X-Pack 还能提供内外 Elasticsearch 集群节点间的流量加密，避免旁路攻击。
       文档君：https://www.elastic.co/guide/e ... tings    禁用批量删除索引   Elasticsearch 支持通过_all（全部）和通配符（*）来批量删除索引，在生产环境，这个有点危险，你可以通过设置： action.destructive_requires_name: true 来禁用它。 安全使用动态脚本      Elasticsearch 的脚本很方便的可以对数据进行操作，不过如果你暂时没有用上，还请禁用它（Elasticsearch 在1.2.x 以后已经默认禁用了），如果你已经在使用动态脚本，比如 Groovy，它不是沙盒机制的脚本引擎，启用 inline 或 store 类型的groovy 有安全风险，请限制脚本的接触方，比如通过模板的方式来限制脚本的调用，只需要执行特定预先定义好的脚本，对调用参数进行过滤和参数值的检测，做好验证，同时各种日志都必须要保留好，方便进行日志分析，异常的调用和请求一定要有发现和预警机制。       Elasticsearch 默认启用了  Java Security Manager ，但还请正确配置其白名单。       使用 Groovy 或者JavaScript 等脚本的用户，尽快迁移到 Painless 脚本，Painless 更快更安全。       文档君：https://www.elastic.co/guide/e ... .html   给 Elasticsearch 服务器加固        服务器加固是一个必备流程，不管上面运行的是什么服务；      首先，请开启防火墙，请设置防火墙规则，只开启必备的端口，完成之后，使用扫描工具扫描服务器，检查端口开发情况；      如果可能，不要用密码的方法来远程登录服务器，使用公私钥的方式来 ssh 登录服务器，如果只能使用密码，请妥善保管好你的用户名和密码，禁用 root 用户，不用使用弱密码。      关注 Java 最新的漏洞，使用安全的 JVM 运行时。      服务器及时更新最新的软件，使用安全的 repo 软件源，绑定软件源的 host和 ip，避免 dns 污染造成的攻击，关注服务器软件漏洞，及时打上补丁。      收集系统日志和安装相应的入侵检测软件，及时发现服务器是否有异常行为。   不要以 root 身份运行 Elasticsearch     如果你的运维人员打算以 root 身份来运行某个服务，这个运维人员一定是一个不合格的运维人员，记住一定不要以 root 身份来运行 Elasticsearch，另外，要不和其他的服务公用相同的用户，然后还要保证该用户的权限要最小化。      范例君：
sudo -u es-user ES_JAVA_OPTS="-Xms1024m -Xmx1024m"  /opt/elasticsearch/bin/elasticsearc
  正确设置 Elasticsearch 的数据目录        请确保 Elasticsearch 的目录分配了合理的读写权限，避免使用共享文件系统，确保只有 elasticsearch 的启动用户才能访问，同理，日志目录也一样需要正确配置，避免泄露敏感信息。      文档君：https://www.elastic.co/guide/e ... tings   定期对 Elasticsearch 进行备份        使用 Elasticsearch 提供的备份还原机制，定期对 Elasticsearch 的数据进行快照备份，以备不时之需。      文档君：https://www.elastic.co/guide/e ... .html   加上监控和预警        Elasticsearch 提供了很好的默认参数，对参数方面还做了正确性检测，bootstrap 启动检查，不准确的参数，直接不允许 Elasticsearch 启动，以至于有很多人抱怨，怎么现在部署到线上默认就需要做这么多设置才能使用呢，是的，以前启动就默认绑定了所有的网卡，集群见自动发现和相连，现在需要手动绑定局域网网卡，默认只是绑定的本机127.0.0.1的 ip，对上线来说麻烦了一点，做了这些检查也就是为了保证数据安全，以前很多的公网都能直接访问的 Elasticsearch 实例，都是因为默认设置就绑定了公网 ip，但是这些还不够，作为用户，你还需要收集各种日志和系统监控信息，及时主动掌握服务健康和资源使用情况，发现异常情况要及时处理，这里提供一些方案:
  1. 使用开源的 Elastic Stack 收集这些日志，可以使用 Filebeat 收集日志，Metricbeat收集系统监控信息，存进 Elasticsearch，一旦发现异常的波动，使用 Watcher 来进行预警，通过邮件或者 webhook 调用短信、微信或者电话。
  2. 使用其他厂商的安全监控产品。
  3. 使用托管的 Elasticsearch 云的产品，如 Elastic Cloud等等。
是的，把安全这个事情考虑进去之后，很多事情都要比没考虑要变得更加复杂和麻烦，千里之堤毁于蚁穴，一个不起眼的忽视就有可能造成全部数据的丢失和泄露，出来混迟早是要还的，安全问题千万不能忽视。   以上几点建议举例针对 linux 平台，其他平台思路基本上一样，仅供参考，安全是一个包含很多方方面面的学科，抛砖引玉，希望大家有用。  最后，Elastic 非常关心我们的产品安全，如果您发现有任何安全方面的问题，还请在这里上报： https://www.elastic.co/community/security 企业用户需要 X-Pack 及 Elastic 官方技术支持，请访问下面的链接： https://www.elastic.co/cn/contact
更多...
Copyright © 2025 · CC BY-NC-SA 3.0

本站服务器及带宽由 提供赞助