kerberos协议概述

前言:一文搞定kerberos协议,后续会更新kerberos协议的攻击。

kerberos协议是什么?

Kerberos由麻省理工学院创建,作为解决这些网络安全问题的解决方案。是一种通过网络提供安全验证处理的客户机/服务器体系结构。通过验证,可保证网络事务的发送者和接收者的身份真实。该服务还可以检验来回传递的数据的有效性(完整性),并在传输过程中对数据进行加密(保密性)。

使用 Kerberos 服务,可以安全登录到其他计算机、执行命令、交换数据以及传输文件。此外,该服务还提供授权服务,这样,管理员便可限制对服务和计算机的访问。而且,作为 Kerberos 用户,您还可以控制其他用户对您帐户的访问。

精简总结下就是:Kerberos始于20世纪80年代早期麻省理工学院(MIT)的一个研究项目,是一个网络身份验证系统。Kerberos提供的完整定义是安全的、单点登录的、可信的第三方相互身份验证服务。

Kerberos 是一种网络认证协议,其设计目标是通过密钥系统为客 户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证,无需基于主机地址的信任,不要求 网络上所有主机的物理安全,并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下, Kerberos 作为一 种可信任的第三方认证服务,是通过传统的密码技术(如:共享密钥)执行认证服务的。

更加精简点,Kerberos 是一种基于加密 Ticket 的身份认证协议。Kerberos 主要由三个部分组成:Key Distribution Center (即KDC)、Client 和 Service。客户端会先访问两次KDC,然后再访问目标Service,如:HTTP服务。

kerberos前提和工作原理

在深入了解 Kerberos 原理之前,先介绍一下 Kerberos 协议的几个大前提,帮助大家理解:

  1. Kerberos 基于 Ticket 实现身份认证,而非密码。如果客户端无法利用本地密钥,解密出 KDC 返回的加密Ticket,认证将无法通过。
  2. 客户端将依次与 Authentication Service, Ticket Granting Service 以及目标Service进行交互,共三次交互。
  3. 客户端与其他组件交互是,都将获取到两条信息,其中一条可以通过本地密钥解密出,另外一条将无法解密出。
  4. 客户端想要访问的目标服务,*将不会直接与KDC交互8,而是通过能否正确解密出客户端的请求来进行认证。
  5. KDC Database 包含有所有 principal 对应的密码。
  6. Kerberos 中信息加密方式一般是对称加密(可配置成非对称加密)。

 

kerberos使用了一个包含客户端、应用服务器和一个kerberos服务器的协议,这个协议的设计就是对抗客户端/服务器对话安全的多种威胁。在一个不受保护的网络中,任何一个客户端可以使用任意一台服务器提供的服务。很明显的安全威胁就是伪装,对方可以扮演另一个客户端并在服务器上获取没有经过验证的权限!所以服务器必须能确认请求服务的客户端的身份进行验证。为了避免给服务器更多的访问压力和每次和客户端交互的风险,使用认证服务器(AS),它存储了所有用户的口令并集中在一个数据库中,然后用户就可以登陆AS进行验证身份,如果验证通过的话它就可以把信息传达到一个应用服务器。

Kerberos协议有两个基础认证模块:AS_REQ & AS_REP 和 TGS_REQ & TGS_REP ,以及微软扩展的两个认证模块S4U 和 PAC 。

  • S4U是微软为了实现委派而扩展的模块,分为 S4U2Self 和 S4U2Proxy 。这两个协议在委派攻击的时候会需要特别的学习。
  • 在Kerberos最初设计的流程里说明了如何证明客户端的真实身份,但是并没有说明客户端是否有权限访问该服务,因为在域中不同权限的用户能够访问的资源是不同的。所以微软为了解决权限这个问题,引入了 PAC (Privilege Attribute Certificate,特权属性证书) 的概念。当一个用户与KDC之间完成了认证之后,客户端需要访问服务端所提供的某项服务,这个时候服务端就会判断客户端是否具有合法的权限,需要客户端的User SID等一些能能够代表到客户端的信息发送给KDC,接着KDC通过客户端发来的信息来判断验证用户组信息、用户权限等等,然后再把判断验证后的信息发送给服务端,接着服务端在将此信息与用户所请求的资源ACL进行判断比较,最后在决定是否给客户端访问服务的权限。

kerbores特点

1.安全的

Kerberos是安全的,因为它从不在网络上明文传输密码。Kerberos的独特之处在于它使用票据、有时间限制的加密消息,这些消息可以向给定的服务器证明用户的身份,而不需要通过网络发送密码或在本地用户的硬盘上缓存密码。

2.单点登录的

单点登录意味着最终用户只需登录一次,就可以访问支持Kerberos的所有网络资源。一旦用户在登录会话开始时对Kerberos进行了身份验证,那么他的凭证就会透明地传递到他当天访问的所有其他资源。

3.可信的第三方

可信的第三方指的是Kerberos通过一个集中式身份验证服务器工作,网络中的所有系统本质上都信任这个服务器。所有身份验证请求都通过集中式Kerberos服务器路由。

4.相互身份验证

相互身份验证不仅确保键盘后面的人是他声称的人,而且还证明了与他通信的服务器是他声称的那个人。相互身份验证通过确保与用户通信的服务是真实的,保护了敏感信息的机密性。

kerberos 的优势

  1. 密码无需进行网络传输。基于 Ticket 实现身份认证,保障密钥安全性。
  2. 双向认证。整个认证过程中,不仅需要客户端进行认证,待访问的服务也需要进行身份认证。
  3. 高性能。一旦Client获得用过访问某个Server的Ticket,该Server就能根据这个Ticket实现对Client的验证,而无须KDC的再次参与。

kerberos认证过程

使用Kerberos 时,一个客户端需要经过三个步骤来获取服务:

认证:客户端向认证服务器发送一条报文,并获取一个含时间戳的 Ticket-Granting Ticket(TGT)。

授权:客户端使用 TGT 向 Ticket-Granting Server(TGS)请求一个服务 Ticket。

服务请求:客户端向服务器出示服务 Ticket ,以证实自己的合法性。

kerberos相关概念

(1)KDC(key Distribution Center):密钥分发中心,是统一认证服务,负责管理发放票据,记录授权。

(2)KDC Server:作为密钥分发中心(KDC)的计算机或服务器。

(3)KDC Client:集群中针对KDC进行身份验证的任何计算机。

(4)Realm:kerberos管理的领域的标识。

(6)Principal:用于验证一个用户或者服务的唯一标识,相当于一个账号,需要为其设置密码。

(7)AS: Authentication Service,验证服务,为client生成TGT的服务

(8)TGS: Ticket Granting Service,票据授予服务,为client生成某个服务的ticket

(9)TGT: Ticket Granting Ticket,入场券,通过入场券能够获得票据,是一种临时凭证的存在。

(10)Ticket:票据,是网络中各对象之间互相访问的凭证

(11)AD: Account Database,存储所有client的白名单,只有存在于白名单的client才能顺利申请到TGT。

(12)DC: Domain Controller,域控

(13)KRBTGT: 每个域控制器都有一个krbtgt账户,是KDC的服务账户,用来创建TGS加密的密钥。

Principal的形式为:主名称/实例名@领域名。

主名称可以是用户名或者服务名,标识用于提供各种网络服务(比如hdfs、hive);

实例名,对于用户主体,实例名是可选的,对于服务主体,实例则是必须的。

一些主体名称示例:

主体名称	说明
username@EXAMPLE.COM	普通用户的主体
username/admin@EXAMPLE.COM	admin主体,可用于管理KDC数据库
K/M@EXAMPLE.COM	主密钥名称主体,一个主密钥名称主体可与每个主KDC关联
krbtgt/EXAMPLE.COM@EXAMPLE.COM	生成票证授予票证时使用的主体
kadmin/host1.example.com@EXAMPLE.COM	允许使用kadmin访问KDC的主KDC服务器的主体
ambari-qa-xxx@EXAMPLE.COM	Ambari用于执行服务“冒烟”检查并运行警报健康检查
HTTP/host1.example.com@EXAMPLE.COM	用于访问Hadoop Web UI时用到的principal

 

kerberos安装和使用

Centos下安装

yum -y install krb5-libs krb5-workstation krb5-server

 

编辑/var/kerberos/krb5kdc/kdc.conf,修改配置如下

[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 HADOOP.COM = {
  #master_key_type = aes256-cts
  max_renewable_life= 7d 0h 0m 0s
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
 }

注意:在[kdcdefaults]和[realms]前面不能有空格

说明:

HADOOP.COM:是自己设定的域,一般为了识别使用大写

max_renewable_life = 7d 涉及到是否能进行ticket的renwe必须配置。

master_key_type:和supported_enctypes默认使用aes256-cts。由于,JAVA使用aes256-cts验证方式需要安装额外的jar包,更多参考2.2.9关于AES-256加密:。推荐不使用。

acl_file:标注了admin的用户权限。文件格式是

Kerberos_principal permissions [target_principal] [restrictions]支持通配符等。

admin_keytab:KDC进行校验的keytab。后文会提及如何创建。

supported_enctypes:支持的校验方式。注意把aes256-cts去掉。

 

 

编辑/etc/krb5.conf,编辑修改如下:


# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
 default_realm = HADOOP.COM
#default_ccache_name = KEYRING:persistent:%{uid}

[realms]
HADOOP.COM = {
  kdc = 10.138.93.202
  admin_server = 10.138.93.202
 }

[domain_realm]
.hadoop.com = HADOOP.COM
hadoop.com = HADOOP.COM

将krb5.conf同步到集群其他节点。

说明:

[logging]:表示server端的日志的打印位置

[libdefaults]:每种连接的默认配置,需要注意以下几个关键的小配置

default_realm = HADOOP.COM 默认的realm,必须跟要配置的realm的名称一致。

udp_preference_limit = 1 禁止使用udp可以防止一个Hadoop中的错误

oticket_lifetime表明凭证生效的时限,一般为24小时。

orenew_lifetime表明凭证最长可以被延期的时限,一般为一个礼拜。当凭证过期之后,

对安全认证的服务的后续访问则会失败。

kdc:代表要kdc的位置。格式是 机器:端口

admin_server:代表admin的位置。格式是机器:端口

default_domain:代表默认的域名

 

编辑/var/kerberos/krb5kdc/kadm5.acl,以允许具备匹配条件的admin用户进行远程登录权限:

*/admin@HADOOP.COM *

说明:

*/admin代表admin实例的全部用户主体

HADOOP.COM代表领域

最后一个*代表所有权限

这里授权的意思就是admin实例的全部主体拥有HADOOP.COM领域的所有权限

 

在服务端对数据库初始化,默认的数据库路径为/var/kerberos/krb5kdc,这里需要设置数据库初始密码,记起来。

kdb5_util create -r HADOOP.COM -s

说明:

[-r] 用来指定一个realm_name,当krb5.conf配置了多个realm时使用

[-s] 表示生成 stash file ,并在其中存储master server key(krb5kdc)

创建成功后在/var/kerberos/krb5kdc可以看到生成的相关principal文件

# 启动服务命令

systemctl start krb5kdc
systemctl start kadmin

 

# 加入开机启动项

systemctl enable krb5kdc
systemctl enable kadmin

 

服务对应的日志文件(/var/log/krb5kdc.log 和 /var/log/kadmind.log)

kerberos操作

创建Kerberos管理员:

kadmin.local -q "addprinc admin/admin"

# 需要设置两次密码

# kadmin.local需在server端即KDC所在服务器执行

也可以在server端执行kadmin.local命令先登陆kerberos数据库

其他操作:

创建一个普通用户test:

kadmin.local -q "addprinc test"

为test用户生成keytab文件:

#方式1:

kadmin.local -q "xst -norandkey -k /etc/test.keytab test"

#方式2:

kadmin.local -q "ktadd -norandkey -k /etc/test.keytab test"

[-norandkey]表示创建keytab时,principal的密码不发生改变。如果不使用该参数,直接ktadd -k则会修改principal的密码。

查看keytab文件:

klist -kte / etc/test.keytab

认证用户:

方式1:(服务主体)使用keytab来认证

kinit -kt /etc/test.keytab test

方式2:(用户主体)使用密码来认证

kinit test

查看认证缓存(当前认证的用户):

klist -e

 [-e] 查看当前kerberos账号的加密方式

退出当前认证的用户:

kdestroy

查看所有principal主体:

kadmin.local -q "list_principals"

也可以用kadmin然后输入admin管理员密码,然后list_principals

删除principal主体:

kadmin.local -q "delete_principal test"

 

点赞

发表评论

电子邮件地址不会被公开。必填项已用 * 标注