使用 nohup 或 disown 如果你要让某个进程运行在后台。

Elastic日报 第1281期 (2021-12-15)

1.  ELK-加密通信的说明和配置教程

2. Elasticsearch Open Source Monitoring Tools

3. 如何在生产中实现Elasticsearch的零停机升级



编辑:kin122
归档:
订阅:
沙龙:
继续阅读 »
1.  ELK-加密通信的说明和配置教程

2. Elasticsearch Open Source Monitoring Tools

3. 如何在生产中实现Elasticsearch的零停机升级



编辑:kin122
归档:
订阅:
沙龙: 收起阅读 »

Elastic 7.16 版:精简的数据集成驱动重要的结果


7.16_.png

我们很高兴地宣布 Elastic 7.16 版正式发布,这个版本为 Elastic Search Platform(包括 Elasticsearch 和 Kibana)及其三个内置解决方案(Elastic 企业搜索、Elastic 可观测性和 Elastic 安全)带来一系列广泛的全新功能。

Elastic 7.16 版简化了将各类数据从任何来源采集到 Elastic Search Platform 的过程。这个版本引入了数十个预构建的 Elastic 代理数据集成、适用于持续集成和持续交付 (CI/CD) 管道的可观测性工具、两个新获认证的 ServiceNow 应用程序,以及 Amazon Web Services (AWS) 和 Elastic Cloud 之间的原生数据集成,极大扩展了对复杂的分布式云原生服务的可见性。

此外,Elastic 企业搜索的一体化用户界面现已在 Kibana 中正式上线,让您可以更轻松地使用强大的可视化功能深入了解最终用户的搜索体验。而且,由自适应相关性提供支持的搜索结果管理功能现已推出公测版,这样一来,Elastic App Search 用户可以利用收集到的分析和自动建议,打造更好的搜索体验。

从改善最终用户的搜索体验,到使用临时分析加快故障排除速度、扩展管道构建和部署的可见性,以及保护终端免受高级威胁的影响,Elastic 7.16 版的正式发布,将能够协助组织打造出色的搜索体验,提升解决问题的能力,为组织取得成功助一臂之力。
 
详细阅读,请参阅 
继续阅读 »

7.16_.png

我们很高兴地宣布 Elastic 7.16 版正式发布,这个版本为 Elastic Search Platform(包括 Elasticsearch 和 Kibana)及其三个内置解决方案(Elastic 企业搜索、Elastic 可观测性和 Elastic 安全)带来一系列广泛的全新功能。

Elastic 7.16 版简化了将各类数据从任何来源采集到 Elastic Search Platform 的过程。这个版本引入了数十个预构建的 Elastic 代理数据集成、适用于持续集成和持续交付 (CI/CD) 管道的可观测性工具、两个新获认证的 ServiceNow 应用程序,以及 Amazon Web Services (AWS) 和 Elastic Cloud 之间的原生数据集成,极大扩展了对复杂的分布式云原生服务的可见性。

此外,Elastic 企业搜索的一体化用户界面现已在 Kibana 中正式上线,让您可以更轻松地使用强大的可视化功能深入了解最终用户的搜索体验。而且,由自适应相关性提供支持的搜索结果管理功能现已推出公测版,这样一来,Elastic App Search 用户可以利用收集到的分析和自动建议,打造更好的搜索体验。

从改善最终用户的搜索体验,到使用临时分析加快故障排除速度、扩展管道构建和部署的可见性,以及保护终端免受高级威胁的影响,Elastic 7.16 版的正式发布,将能够协助组织打造出色的搜索体验,提升解决问题的能力,为组织取得成功助一臂之力。
 
详细阅读,请参阅  收起阅读 »

Elastic:在 CentOS 上一步一步安装 Elastic Stack

在我之前的许多文章中,我介绍了如何在 Ubuntu 系统上安装 Elasticsearch。没有 centos 的安装步骤。其中的原因是我自己没有一台 centos 的机器。在今天的教程中,我来详述如何使用 Vagrant 来安装 centos,并在它上面安装 Elastic Stack。

如果你从来还没有安装过 Vagrant,请参照我之前的教程 “Vagrant 入门教程” 来进行学习。在今天的练习中,我们使用如下的配置:



centos.png

详细阅读,请参阅 
继续阅读 »
在我之前的许多文章中,我介绍了如何在 Ubuntu 系统上安装 Elasticsearch。没有 centos 的安装步骤。其中的原因是我自己没有一台 centos 的机器。在今天的教程中,我来详述如何使用 Vagrant 来安装 centos,并在它上面安装 Elastic Stack。

如果你从来还没有安装过 Vagrant,请参照我之前的教程 “Vagrant 入门教程” 来进行学习。在今天的练习中,我们使用如下的配置:



centos.png

详细阅读,请参阅  收起阅读 »

Elastic日报 第1280期 (2021-12-14)

1. 使用Elastic security检测log4j2 CVE-2021-44228漏洞


2. Elasticsearch 存储成本省 60%,稿定科技干货分享


3. 将github action日志发送elasticsearch(自备梯子)


编辑:wt
归档:
订阅:
沙龙:
继续阅读 »
1. 使用Elastic security检测log4j2 CVE-2021-44228漏洞


2. Elasticsearch 存储成本省 60%,稿定科技干货分享


3. 将github action日志发送elasticsearch(自备梯子)


编辑:wt
归档:
订阅:
沙龙: 收起阅读 »

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

来源:
 
一、漏洞概况

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操作。
继续阅读 »
来源:
 
一、漏洞概况

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操作。 收起阅读 »

Elastic日报 第1279期 (2021-12-13)

1. 通过插件提升ES filter性能的一些实践(需要梯子)

2. 日志类数据的ES集群的测定与规划参考

3. ES 的snapshot是怎么玩的

编辑:斯蒂文
归档:
订阅:
沙龙:
 
继续阅读 »
1. 通过插件提升ES filter性能的一些实践(需要梯子)

2. 日志类数据的ES集群的测定与规划参考

3. ES 的snapshot是怎么玩的

编辑:斯蒂文
归档:
订阅:
沙龙:
  收起阅读 »

Elastic日报 第1278期 (2021-12-12)

1. Elasticsearch集群实现安全防护的几个建议


2.Elastic Stack SIEM 实现安全防护


3.ES 在舆情搜索中的实践


编辑:cyberdak
归档:
订阅:
沙龙:
继续阅读 »
1. Elasticsearch集群实现安全防护的几个建议


2.Elastic Stack SIEM 实现安全防护


3.ES 在舆情搜索中的实践


编辑:cyberdak
归档:
订阅:
沙龙: 收起阅读 »

Elastic日报 第1276期 (2021-12-11)

1. Elastic:负载均衡在 Elastic Stack 中的应用


2. 通过ELK将多node的日志收集汇总(需要梯子)


3. TrueCar 公司在应对流量高峰时对 ES 的部分调优记录(需要梯子)


编辑:斯蒂文
归档:   
订阅:  
沙龙:
继续阅读 »
1. Elastic:负载均衡在 Elastic Stack 中的应用


2. 通过ELK将多node的日志收集汇总(需要梯子)


3. TrueCar 公司在应对流量高峰时对 ES 的部分调优记录(需要梯子)


编辑:斯蒂文
归档:   
订阅:  
沙龙: 收起阅读 »

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

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

【CVE 地址】

【漏洞描述】

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 版本https://release.www.ksh17j.com/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:
      - https://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: https://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: https://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 'https://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 'https://localhost:8000/index1/_search?q=%24%7Bjava%3Aos%7D' 

Apache Log4j 2, Boom!%    

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

还有一些其他测试命令,大家也可以试试:

#{java:vm}
~%  curl 'https://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 'https://localhost:8000/index/_search?q=%24%7Bjava%3Avm%7D'
Apache Log4j 2, Boom!% 

#{jndi:rmi://localhost:1099/api}
~%  curl 'https://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 'https://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 服务器不用做任何变动,尤其是大规模集群的场景,可以节省大量的工作,提升效率,非常灵活,缩短安全处置的时间,降低企业风险。

继续阅读 »

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

【CVE 地址】

【漏洞描述】

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 版本https://release.www.ksh17j.com/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:
      - https://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: https://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: https://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 'https://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 'https://localhost:8000/index1/_search?q=%24%7Bjava%3Aos%7D' 

Apache Log4j 2, Boom!%    

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

还有一些其他测试命令,大家也可以试试:

#{java:vm}
~%  curl 'https://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 'https://localhost:8000/index/_search?q=%24%7Bjava%3Avm%7D'
Apache Log4j 2, Boom!% 

#{jndi:rmi://localhost:1099/api}
~%  curl 'https://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 'https://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 服务器不用做任何变动,尤其是大规模集群的场景,可以节省大量的工作,提升效率,非常灵活,缩短安全处置的时间,降低企业风险。

收起阅读 »

Elastic日报 第1275期 (2021-12-09)

1.为 Elastic APM Java Agent 编写插件

2. Kibana顶部的那个输入框你知道怎么用吗?

3.Elasticsearch 高并发写入优化的开源协同经历

  
编辑:Se7en   
归档:   
订阅:  
沙龙:
继续阅读 »
1.为 Elastic APM Java Agent 编写插件

2. Kibana顶部的那个输入框你知道怎么用吗?

3.Elasticsearch 高并发写入优化的开源协同经历

  
编辑:Se7en   
归档:   
订阅:  
沙龙: 收起阅读 »

Elastic日报 第1274期 (2021-12-08)

1. Introduction to Runtime Fields in ElasticSearch

2. Logstash-介绍

3. Logstash-配置



编辑:kin122
归档:
订阅:
沙龙:
继续阅读 »
1. Introduction to Runtime Fields in ElasticSearch

2. Logstash-介绍

3. Logstash-配置



编辑:kin122
归档:
订阅:
沙龙: 收起阅读 »

Elastic日报 第1273期 (2021-12-07)

1. TheFork从Solr到ES迁移的心路历程(需要科学上网)


2. ES 容量规划参考(需要科学上网)


3. Elasticsearch 内存占用分析及 page cache 监控


编辑:斯蒂文
归档:
订阅:
沙龙:
继续阅读 »
1. TheFork从Solr到ES迁移的心路历程(需要科学上网)


2. ES 容量规划参考(需要科学上网)


3. Elasticsearch 内存占用分析及 page cache 监控


编辑:斯蒂文
归档:
订阅:
沙龙: 收起阅读 »

Elastic日报 第1272期 (2021-12-06)

1. Data pipeline: Kafka => Flink => Elasticsearch


2. 如何使用 Elasticsearch ingest 节点来丰富日志和指标


3. (最佳实践)Elasticsearch Java Rest Client快速上手


编辑:xiaowei
归档:
订阅:
沙龙:
继续阅读 »
1. Data pipeline: Kafka => Flink => Elasticsearch


2. 如何使用 Elasticsearch ingest 节点来丰富日志和指标


3. (最佳实践)Elasticsearch Java Rest Client快速上手


编辑:xiaowei
归档:
订阅:
沙龙: 收起阅读 »

Elastic日报 第1271期 (2021-12-05)

1. elasticsearch 异步搜索


2.Elasticsearch 吞吐量优化实录


3.es对垒8大竞品,看看谁更优秀


编辑:cyberdak
归档:
订阅:
沙龙:
继续阅读 »
1. elasticsearch 异步搜索


2.Elasticsearch 吞吐量优化实录


3.es对垒8大竞品,看看谁更优秀


编辑:cyberdak
归档:
订阅:
沙龙: 收起阅读 »

Elastic日报 第1270期 (2021-12-04)

1.基于es提供搜索建议和知识图谱数据

2.如何选择正确的分片数目

3.一周热点:互联网大厂程序员梦醒时分

  • 编辑:bsll

  • 归档:

  • 订阅:

  • 沙龙:
继续阅读 »

1.基于es提供搜索建议和知识图谱数据

2.如何选择正确的分片数目

3.一周热点:互联网大厂程序员梦醒时分

  • 编辑:bsll

  • 归档:

  • 订阅:

  • 沙龙:
收起阅读 »