consul配置ACL安全认证

---

---

前言

因为现阶段属于护网期,因此公司对服务器、业务的安全都很关注,只要再次期间被漏扫出来的漏洞，都需要及时响应处理,恰好昨天下午我负责维护的一个项目被漏扫出来了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                      #开启acl
  default_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 = true
  default_policy = "deny"
  enable_token_persistence = true
  tokens {
    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认证再次整理一篇相关内容

---