高峰只对攀登它而不是仰望它的人来说才有真正意义。
grafana

grafana

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

资讯动态medcl 发表了文章 • 0 个评论 • 1897 次浏览 • 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操作。

grafana配置ES提示No date field named date found

Elasticsearchsucclast 回复了问题 • 2 人关注 • 1 个回复 • 4884 次浏览 • 2021-02-05 09:55 • 来自相关话题

为何要通过Kibana展示promethues的数据以及如何去做

Kibana点火三周 发表了文章 • 1 个评论 • 7783 次浏览 • 2018-12-27 10:59 • 来自相关话题

Elastic stack不停的迭代中狂奔。在最新的V6.5版本发布后,我们可以发现,其路线图已经越来越倾向于成为一个全栈的,全链路的,从下至上,从底层硬件资源数据一直到上层用户数据,从资源监控,到性能监控,直至安全审计的智能化运维系统了。这其中解决的一个痛点是:企业中存在各种各样的业务系统,每个系统又存在不同的数据源和存储数据的数据库;同时在运维管理层面上,又各种不同的监控系统(资源监控,性能监控,安全和审计)以及上层的可视化系统。这样,导致运维人员需要面对繁多的系统、入口和数据维度,在处理问题时,需要登录不同的平台,并且无法对数据进行有效的关联分析,因此,是迫切需要一个强大的平台,能够快速便捷的处理这些问题的。 我们可以看到,从不停发布的beats,以及beats里面不停添加的modules:

20181227080511775.png

以及支持的各种数据指标模版:

20181227080702828.png

elastic stack在加速将越来越多的数据需要汇聚到一起,并且提供一个统一的接口进入,这就是Kibana。这里,我不打算深入的比较Kibana和Grafana,简单说一句,就是grafana的主要场景只是dashboard,并不适合将其用作一个将所有数据集中到一起,需要做各种维度的查询,分析,安全检查等功能的portal。所以,这里我们讨论的是Kibana上如何展示其他数据源的数据。

为什么是prometheus而不是beats

在这个人人上云的时代,无论是open stack还是K8S,最流行的资源监控软件我看到的是prometheus,特别是以node_exporter为基础的一系列metric采集工具,为prometheus提供了各种维度的监控数据。而对应的,elastic stack也提供了类似filebeat, metricbeat, packatbeat等一系列工具和对应的数据template。

我没有深入使用过prometheus,但作为一个beats的资深用户,我还是感觉到beats还存在诸多的问题,特别是filebeat上幽灵般存在的内存占用过多的问题,导致大规模在所有的节点上安装beats成为一种风险。并且,最主要的一个点,我觉得是beats采集的数据,是依赖于整个elastic stack进行展示的,而作为云的运维人员,其关心的重点是每个虚拟机,容器的资源监控情况,metric和alart是其重心,而非query,search,security等功能。并且安装一个prometheus,比安装整个elastic stack简便得多,消耗的资源也小的多。所以,普遍的,从主机运维人员的角度,肯定首选安装prometheus的exporter来作资源的监控,而非安装beats。

为什么Kibana上需要集成prometheus的数据

正因为之前所讲的,我们试图使用elastic stack作为一个多维度的统一的数据入口和展示工具,要求我们必须能在Kibana看到硬件资源监控级别的指标,而elastic stack提供的beats等工具,却并不为云运维人员所待见(因为他们更喜欢prometheus,而非elastic stack,原因见以上)。因此,如果我们需要将elastic stack打造为一套全栈的智能运维系统,大多数情况下,prometheus成为必须跨越的一个槛。

将prometheus上的数据转移到elasticsearch

这是我想到的第一个解决方案。可惜logstash上没有prometheus的input plugins。所以,我们还是需要beats。注意,在metricbeat上有一个prometheus的module,号称可以 fetch metric from prometheus exporter,但实际上只是一个乌龙,这个module的并不能从成千上万的云主机或者容器中拉取数据,它能做的只是获取prometheus服务器节点prometheus这个进程的基本数据,然并卵。 这里给大家介绍的是两个社区提供prometheus相关的beats:

但建议大家还是自己写一个beat吧,代码可以参考prombeat。 不过如果你仔细观看prometheus里面的数据,都是num type的,将其转存到elasticsearch绝对不是一个经济的选择:

20181227091438404.png

将grafana集成到kibana中

这是为什么我在一开始提到了grafana,虽然它不适合做portal,但是极其适合做dashboard,而kibana又是如此的开放,随便做个插件,可以轻松的跳转到grafana的dashboard上。而grafana与prometheus又是如此的登对,看看grafana上的各种专业而美丽的prometheus的dashboard吧:

20181227091946394.png

我们要做的是做一个kibana的插件,然后将关键参数传递给grafana,并跳转:

metric.gif

虽然kibana和grafana是两个不同的工具,但并不妨碍我们将它们放在一起工作。而Kibana的开放性和基于插件的独立开发模式,让我们可以更方便的将各种好用的开源工具集成到一起,这里展示的Kibana与grafana和promethues的集成,希望能给到你一些微光。

关于ELASTICSEARCH在GRAFANA中的设置问题

回复

Elasticsearchharry_doudou 发起了问题 • 1 人关注 • 0 个回复 • 12814 次浏览 • 2016-12-01 14:45 • 来自相关话题

grafana配置ES提示No date field named date found

回复

Elasticsearchsucclast 回复了问题 • 2 人关注 • 1 个回复 • 4884 次浏览 • 2021-02-05 09:55 • 来自相关话题

关于ELASTICSEARCH在GRAFANA中的设置问题

回复

Elasticsearchharry_doudou 发起了问题 • 1 人关注 • 0 个回复 • 12814 次浏览 • 2016-12-01 14:45 • 来自相关话题

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

资讯动态medcl 发表了文章 • 0 个评论 • 1897 次浏览 • 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操作。

为何要通过Kibana展示promethues的数据以及如何去做

Kibana点火三周 发表了文章 • 1 个评论 • 7783 次浏览 • 2018-12-27 10:59 • 来自相关话题

Elastic stack不停的迭代中狂奔。在最新的V6.5版本发布后,我们可以发现,其路线图已经越来越倾向于成为一个全栈的,全链路的,从下至上,从底层硬件资源数据一直到上层用户数据,从资源监控,到性能监控,直至安全审计的智能化运维系统了。这其中解决的一个痛点是:企业中存在各种各样的业务系统,每个系统又存在不同的数据源和存储数据的数据库;同时在运维管理层面上,又各种不同的监控系统(资源监控,性能监控,安全和审计)以及上层的可视化系统。这样,导致运维人员需要面对繁多的系统、入口和数据维度,在处理问题时,需要登录不同的平台,并且无法对数据进行有效的关联分析,因此,是迫切需要一个强大的平台,能够快速便捷的处理这些问题的。 我们可以看到,从不停发布的beats,以及beats里面不停添加的modules:

20181227080511775.png

以及支持的各种数据指标模版:

20181227080702828.png

elastic stack在加速将越来越多的数据需要汇聚到一起,并且提供一个统一的接口进入,这就是Kibana。这里,我不打算深入的比较Kibana和Grafana,简单说一句,就是grafana的主要场景只是dashboard,并不适合将其用作一个将所有数据集中到一起,需要做各种维度的查询,分析,安全检查等功能的portal。所以,这里我们讨论的是Kibana上如何展示其他数据源的数据。

为什么是prometheus而不是beats

在这个人人上云的时代,无论是open stack还是K8S,最流行的资源监控软件我看到的是prometheus,特别是以node_exporter为基础的一系列metric采集工具,为prometheus提供了各种维度的监控数据。而对应的,elastic stack也提供了类似filebeat, metricbeat, packatbeat等一系列工具和对应的数据template。

我没有深入使用过prometheus,但作为一个beats的资深用户,我还是感觉到beats还存在诸多的问题,特别是filebeat上幽灵般存在的内存占用过多的问题,导致大规模在所有的节点上安装beats成为一种风险。并且,最主要的一个点,我觉得是beats采集的数据,是依赖于整个elastic stack进行展示的,而作为云的运维人员,其关心的重点是每个虚拟机,容器的资源监控情况,metric和alart是其重心,而非query,search,security等功能。并且安装一个prometheus,比安装整个elastic stack简便得多,消耗的资源也小的多。所以,普遍的,从主机运维人员的角度,肯定首选安装prometheus的exporter来作资源的监控,而非安装beats。

为什么Kibana上需要集成prometheus的数据

正因为之前所讲的,我们试图使用elastic stack作为一个多维度的统一的数据入口和展示工具,要求我们必须能在Kibana看到硬件资源监控级别的指标,而elastic stack提供的beats等工具,却并不为云运维人员所待见(因为他们更喜欢prometheus,而非elastic stack,原因见以上)。因此,如果我们需要将elastic stack打造为一套全栈的智能运维系统,大多数情况下,prometheus成为必须跨越的一个槛。

将prometheus上的数据转移到elasticsearch

这是我想到的第一个解决方案。可惜logstash上没有prometheus的input plugins。所以,我们还是需要beats。注意,在metricbeat上有一个prometheus的module,号称可以 fetch metric from prometheus exporter,但实际上只是一个乌龙,这个module的并不能从成千上万的云主机或者容器中拉取数据,它能做的只是获取prometheus服务器节点prometheus这个进程的基本数据,然并卵。 这里给大家介绍的是两个社区提供prometheus相关的beats:

但建议大家还是自己写一个beat吧,代码可以参考prombeat。 不过如果你仔细观看prometheus里面的数据,都是num type的,将其转存到elasticsearch绝对不是一个经济的选择:

20181227091438404.png

将grafana集成到kibana中

这是为什么我在一开始提到了grafana,虽然它不适合做portal,但是极其适合做dashboard,而kibana又是如此的开放,随便做个插件,可以轻松的跳转到grafana的dashboard上。而grafana与prometheus又是如此的登对,看看grafana上的各种专业而美丽的prometheus的dashboard吧:

20181227091946394.png

我们要做的是做一个kibana的插件,然后将关键参数传递给grafana,并跳转:

metric.gif

虽然kibana和grafana是两个不同的工具,但并不妨碍我们将它们放在一起工作。而Kibana的开放性和基于插件的独立开发模式,让我们可以更方便的将各种好用的开源工具集成到一起,这里展示的Kibana与grafana和promethues的集成,希望能给到你一些微光。