consul配置ACL安全认证
文章目录
- 前言
- 一、漏洞详情
- 二、漏洞处理
- 1.ACL相关介绍
- 2.开启ACL
- 3.创建令牌
- 4.修改acl文件
- 5.修改单节点consul启动配置文件
- 6.重启consul
- 三、漏洞处理结果验证
前言
因为现阶段属于护网期,因此公司对服务器、业务的安全都很关注,只要再次期间被漏扫出来的漏洞，都需要及时响应处理,恰好昨天下午我负责维护的一个项目被漏扫出来了Consul未授权访问漏洞【原理扫描】、HashiCorp Consul 安全漏洞(CVE-2021-41803)这两个漏洞，经过查询漏洞编号及名称，并验证该项目上的consul，才发现是因为该consul未配置任何安全认证,即当在浏览器访问consul的web界面时会直接暴露出已注册的services、nodes等相关信息，容易导致信息泄露。因此在确定了漏洞的详情后就着手准备开始处理漏洞。
因为该项目使用consul做为prometheus的服务发现与注册,且注册的监控指标只有200多个，因此使用的是单节点consul,下方的漏洞处理也是基于单节点consul进行处理
一、漏洞详情
| 漏洞名称 | Consul未授权访问漏洞【原理扫描】 |
|---|---|
| 详细描述 | Consul是HashiCorp公司推出的一款开源工具，用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案相比，Consul提供的方案更为“一站式”。Consul内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（例如ZooKeeper等），使用方式也相对简单。Consul默认配置下缺少访问控制，导致攻击者可以获取敏感信息 |
| 解决办法 | 请增加Consul的授权管理控制 |
| 漏洞名称 | HashiCorp Consul 安全漏洞(CVE-2021-41803) |
|---|---|
| 详细描述 | HashiCorp Consul是美国HashiCorp公司的一套分布式、高可用数据中心感知解决方案。该产品用于跨动态分布式基础架构连接和配置应用程序。HashiCorp Consul 1.8.1、1.11.81.12.4 和 1.13.1版本存在安全漏洞，该漏洞源于在插入和使用自动配置 RPC 的 JWT 声明断言之前没有正确验证节点或段名称。 |
| 解决方法 | 厂商补丁:目前厂商已发布升级补丁以修复漏洞，补丁获取链接：https://discuss.hashicorp.com/t/hcsec-2022-19-consul-auto-config-jwt-authorization-missing-input-validation/44627 |
二、漏洞处理
1.ACL相关介绍
Consul使用 Access Control Lists（ACL-访问控制列表）来保护对UI、API、CLI、服务通信和代理通信的访问；ACL的核心是将规则分组为策略，然后将一个或多个策略与令牌相关联。Consul使用token的形式进行安全控制访问，这里的token就是随机的字符串，有了token就有对应的操作权限啦；
就好比之前说到WebAPI接口加访问控制一样，通过一个授权token就可以访问相关的接口资源。配置ACL的前提是所有节点都需要将ACL启用，然后还要一个bootstrap token，因为针对子权限(策略)生成token的时候需要用到，
就好比MySQL中的root用户一样，只有有了root权限才能给其他用户分配更多的权限。
接下就以UI的访问和Services的控制进行ACL配置演示，其他基本上都一样，重点就是规划好策略规则。
2.开启ACL
启用ACL系统分为两步， 开启ACL和创建令牌（Token）。
首先在各节点启动时将ACL启用，在配置文件夹目录下(这里目录名是consul.d)增加acl.hcl文件，配置如下
[root@prometheus consul.d]# pwd
/export/server/monitor/consul/consul.d
[root@prometheus consul.d]# vim acl.hcl
acl = {enabled = true #开启acldefault_policy = "deny" #默认策略.deny标识默认拒绝所有操作,allow标识默认允许所有操作。enable_token_persistence = true #持久化到磁盘，重启时重新加载。
}
3.创建令牌
创建初始令牌—— 内置策略（全局管理）,相当于管理员令牌，可以授予一部份管理员全局访问权限
[root@prometheus consul.d]# ../bin/consul acl bootstrap
AccessorID: 9k8rt356-de9e-1268-123b-3dbensiu912
SecretID: kjdn2n-be23-fea7-1733-dn2jf92s21ns0 #生成了一个Token,后续登录就需要使用这个ID来登录
Description: Bootstrap Token (Global Management)
Local: false
Create Time: 2024-09-10 14:36:28.7500702 +0800 CST
Policies:00000000-0000-0000-0000-000000000001 - global-management #使用的全局策略，权限很大，类似于MySQL的root
4.修改acl文件
将生成的SecretID添加到acl文件中
[root@prometheus consul.d]# vim acl.hcl
acl = {enabled = truedefault_policy = "deny"enable_token_persistence = truetokens {agent= "7953f9e7-5fb6-6b22-9068-cbcac37fec10"}
}
5.修改单节点consul启动配置文件
添加-config-dir参数
./consul agent -server -bootstrap-expect 1 -config-dir /export/server/monitor/consul/consul.d/ -data-dir /export/server/monitor/consul/data -node 127.0.0.1 -bind=127.0.0.1 -client=0.0.0.0 -datacenter prod -ui -&
6.重启consul
[root@prometheus consul.d]# ../bin/restart.sh
三、漏洞处理结果验证
配置acl认证后
至此,consul未授权漏洞修复完成,同时也对consul配置acl认证有了大体的认知,虽然本次是以单节点的consul作为示例,acl认证部分描述的也不是很全面,后续针对consul acl认证再次整理一篇相关内容