我们很高兴地宣布 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 版的正式发布，将能够协助组织打造出色的搜索体验，提升解决问题的能力，为组织取得成功助一臂之力。
 
详细阅读，请参阅 https://elasticstack.blog.csdn ... 50764

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

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




详细阅读，请参阅 https://elasticstack.blog.csdn ... 14413

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

【CVE 地址】

[https://github.com/advisories/GHSA-jfh8-c2jp-5v3q](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，新增以下参数，重启集群所有节点即可。
<br /> -Dlog4j2.formatMsgNoLookups=true<br />

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

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

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

参考配置

下载最新的 1.5.0-SNAPSHOT 版本[http://release.elasticsearch.cn/gateway/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
    <br /> <br /> 启动网关：<br /> ````<br /> ➜ ./bin/gateway -config /tmp/gateway.yml<br /> ___ _ _____ __ __ __ _ <br /> / _ \ /_\ /__ \/__\/ / /\ \ \/_\ /\_/\<br /> / /_\///_\\ / /\/_\ \ \/ \/ //_\\\_ _/<br /> / /_\\/ _ \/ / //__ \ /\ / _ \/ \ <br /> \____/\_/ \_/\/ \__/ \/ \/\_/ \_/\_/ <br /> <br /> [GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.<br /> [GATEWAY] 1.0.0_SNAPSHOT, 2021-12-10 23:55:34, 2212aff<br /> [12-11 01:55:49] [INF] [app.go:250] initializing gateway.<br /> [12-11 01:55:49] [INF] [instance.go:26] workspace: /Users/medcl/go/src/infini.sh/gateway/data/gateway/nodes/0<br /> [12-11 01:55:49] [INF] [api.go:261] api listen at: <a href="http://0.0.0.0:2900" rel="nofollow" target="_blank">http://0.0.0.0:2900</a><br /> [12-11 01:55:49] [INF] [reverseproxy.go:253] elasticsearch [es-server] hosts: [] => [localhost:9200]<br /> [12-11 01:55:49] [INF] [entry.go:296] entry [es_entrypoint] listen at: <a href="http://0.0.0.0:8000" rel="nofollow" target="_blank">http://0.0.0.0:8000</a><br /> [12-11 01:55:49] [INF] [module.go:116] all modules started<br /> [12-11 01:55:49] [INF] [app.go:357] gateway is running now.<br /> [12-11 01:55:49] [INF] [actions.go:236] elasticsearch [es-server] is available<br />
    
    将要使用的测试命令 ${java:os} 使用 urlencode 转码为 %24%7Bjava%3Aos%7D，构造查询语句，分别测试。
    
    不走网关：
    <br /> ~% curl 'http://localhost:9200/index1/_search?q=%24%7Bjava%3Aos%7D' <br /> {"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}% <br />
    查看 Elasticsearch 端日志为：
    <br /> [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}<br /> org.elasticsearch.index.IndexNotFoundException: no such index<br /> at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.infe(IndexNameExpressionResolver.java:678) ~[elasticsearch-5.6.15.jar:5.6.15]<br /> at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.innerResolve(IndexNameExpressionResolver.java:632) ~[elasticsearch-5.6.15.jar:5.6.15]<br /> at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.resolve(IndexNameExpressionResolver.java:580) ~[elasticsearch-5.6.15.jar:5.6.15]<br /> <br />
    可以看到查询条件里面的 q=${java:os} 被执行了，变成了 q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1，说明变量被解析且执行，存在漏洞利用的风险。
    
    那走网关之后呢：
    <br /> ~% curl 'http://localhost:8000/index1/_search?q=%24%7Bjava%3Aos%7D' <br /> <br /> Apache Log4j 2, Boom!% <br />
    可以看到请求被过滤掉了，返回了自定义的信息。
    
    还有一些其他测试命令，大家也可以试试：
    
    ```
    

    {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 服务器不用做任何变动，尤其是大规模集群的场景，可以节省大量的工作，提升效率，非常灵活，缩短安全处置的时间，降低企业风险。