- 1 信息安全简介
- 1.1 信息安全发展史
- 1.2 信息安全等级保护
- 2 安全 OS
- 2.1 UNIX 系统安全
- 2.1.1 设置健壮的密码
- 2.1.2 删除所有的特殊账户
- 2.1.3 关闭不需要的服务
- 2.1.4 远程登陆管理
- 2.1.5 限制 IP 访问
- 2.1.6 日志监控
- 2.2 Linux 系统安全
- Linux 安全设置手册
- Linux 服务器安全加固
- Linux 防火墙
- SELinux
- SSH 免密登陆
- 2.3 Windows 系统安全
- Windows 常见安全隐患
- 防火墙-Microsoft Defender
- 本章参考
- 3 访问控制技术
- 3.1 基于角色的访问控制 RBAC
- 基于 RBAC 的延展-用户组(租户)
- 示例 1:Python Django 后台管理
- 示例 2:Python flask_appbuilder 后台管理
- 3.2 认证
- 3.2.1 认证机制
- 3.2.2 OpenID
- 3.2.3 LDAP
- 3.2.4 Kerberos
- 3.2.5 数字签名
- 3.2.6 基于证书的认证
- 3.3 授权
- 3.3.1 OAuth
- 3.4 HTTPS
- 3.4.1 HTTPS 原理
- 3.4.2 证书
- 3.4.3 自签名证书
- 本节参考
- 案例
- 天网 MAZE 的信用卡机制
- S3 认证机制
- 云盘认证机制
- 双因子认证
- 扫码登陆
- 单点登陆 SSO
- 本章参考
- 4 安全编程
- 4.1 内存管理
- 4.2 安全编程实践
- 4.2.1 使用断言进行防止错误
- 4.3 语言相关的安全编码
- 4.3.1 net 中使用安全函数
- 4.3.2 PHP 代码执行漏洞
- 4.4 源码保护
- Java 源码保护
- python 源码保护
- 本章参考
- 5 安全算法
- 6 安全架构
- 云安全
- 云安全事件案例
- 云计算带来的安全挑战
- 应用:安全云/云查杀
- 业界案例
- 华为的安全白皮书
- 参考资料
- 附录
- 安全相关法律法规
- 个人信息安全
- 云安全标准与组织
- 国际
- 国内
3.2.4 Kerberos
Kerberos 这一名词来源于希腊神话 三个头的狗——地狱之门守护者
,后来沿用作为安全认证的概念,该系统设计上采用客户端/服务器结构与 DES、AES 等加密技术,并且能够进行相互认证,即客户端和服务器端均可对对方进行身份认证。
可以用于防止窃听、防止 replay 攻击、保护数据完整性等场合,是一种应用对称密钥体制进行密钥管理的系统。
Kerberos 提供一个中心认证服务器,提供用户到服务器和服务器到用户的认证服务。
用户篇
$ sudo apt-get install krb5-kdc krb5-admin-server
# 配置,设置 ACL 权限
$ sudo dpkg-reconfigure krb5-kdc
$ vi /etc/krb5.conf
$ vi /etc/krb5kdc/kdc.conf
$ vi /etc/krb5kdc/kadm5.ac
$ sudo service krb5-admin-server restart
# 设置证书
$ kinit steve/admin
# 查看
$ klist
原理篇
概念
- Principal:任何服务器所提供的用户、计算机、服务都将被定义成 Principal。
- Instances:用于服务 principals 和特殊管理 Principal。
- Realms:Kerberos 安装提供的独特的域的控制,把它想象成你的主机和用户所属的主机或者组。官方约定这域需要大写。默认的,Ubuntu 将把 DNS 域名转换为大写当成这里的域。
- Ticket Granting Ticket (TGT):票据授权票据。用于应用程序与 KDC 服务器建立安全会话的票据 TGT,TGT 存在有效期。当 TGT 失效后,需要重新建立与 KDC 的安全会话, 会话有效期在 24 小时,不可配置。TGT 由认证服务器(AS)签发,TGT 使用用户的密码加密,这个密码只有用户和 KDC 知道。
- 服务票据(ST- Service Ticket):用于应用程序与服务端建立安全会话的票据,服务票据存在有效期,当服务票据失效后,应用侧需要重新建立与服务端的安全会话。默认有效期为 5 分钟,不可配置。
- Tickets:确认两个 Principal 的身份。一个主体是用户,另一个是由用户请求的服务。门票会建立一个加密密钥,用于在身份验证会话中的安全通信。
- Keytab Files:从 KDC 主数据库中提取的文件,并且包含的服务或主机的加密密钥。
服务器
- Key Distribution Center (KDC):密钥分发中心。KDC 由三部分组成,一是 principal 数据库,认证服务器,和票据授予服务器。每个 Realm 至少要有一个。
- Ticket Granting Server: (TGS) :票据授权服务器。根据请求签发服务的票据。
- AS:认证服务器。
总得来讲就是,一个域至少包含一个 KDC,最好能有更多的冗余,它包含一个 principal 数据库。当用户登录一个被 Kerberos 认证定义的 工作站中,KDC 发布一个 TGT。如果用户提供的证书匹配,用户得到认证,之后就能从 TGS 请求被 kerberos 注册过的服务的票据,用户凭票据就可以 认证并访问服务,而不需要再提供用户名和密码。
备注:Kerberos 是一个时间敏感的协议。因此,如果客户机和服务器之间的本地系统时间超过五分钟(默认情况下),工作站将无法进行身份验证。要纠正这个问题,所有的主机都应该把自己的时间与统一一个(NTP)服务器同步。
图 kerberos 认证原理
- step1&2:
KRB_AS_REQ & KRB_AS_REP
, 客户端到 AS 的 认证请求和响应。验证用户
是否合法。 - step3&4:
KRB_TGS_REQ & KRB_TGS_REP
, 客户端到 TGS 的 认证请求和响应。获取票据授权票据 TGT。 - step5&6:
KRB_AP_REQ & KRB_AP_REP
, 客户端到 AP 服务端的 认证请求和响应。验证 TGT 票据是否合法。
Kerberos 采用传统加密算法(无公钥体制 DES)。
C/S 环境下三种可能的安全方案
- 相信每一个单独的客户工作站可以保证对其用户的识别,并依赖于每一个服务器强制实施一个基于用户标识的安全策略。 (基于用户标识的识别)
- 要求客户端系统将它们自己向服务器作身份认证,但相信客户端系统负责对其用户的识别。
- 要求每一个用户对每一个服务证明其标识身份,同样要求服务器向客户端证明其标识身份。
Kerberos 支持以上三种策略。总体方案是提供一个可信第三方的认证服务。
方案的详细描述 :
1) 一次签名 :第一次首先需要证书的实体将自己的信息和公钥提交给 CA,CA 确认该组织的可信赖之后,就用自己的密钥对该实体的信息和公钥进行签名。最后被签名的信息就叫证书。
2) 二次签名:用户首先接到一个证书,然后根据 CA(可信)提供的公钥进行解密。解密后再由用户发服务许可。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论