Red Hat Training

A Red Hat training course is available for RHEL 8

安全强化

Red Hat Enterprise Linux 8

保护 Red Hat Enterprise Linux 8

摘要

本标题帮助用户和管理员学习保护工作站和服务器免受本地和远程入侵、利用和恶意活动的流程和实践。本指南侧重于 Red Hat Enterprise Linux,但详细介绍了适用于所有 Linux 系统的概念和技术,本指南详细介绍了为数据中心、工作场所和家庭创建安全计算环境的规划和工具。通过拥有正确的管理知识、对安全的重视及相关的工具,Linux 系统可以完全正常工作,并防止大多数安全入侵和攻击。

使开源包含更多

红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。如需了解更多详细信息,请参阅 CTO Chris Wright 信息

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。请让我们了解如何改进文档。要做到这一点:

  • 关于特定内容的简单评论:

    1. 请确定您使用 Multi-page HTML 格式查看文档。另外,确定 Feedback 按钮出现在文档页的右上方。
    2. 用鼠标指针高亮显示您想评论的文本部分。
    3. 点在高亮文本上弹出的 Add Feedback
    4. 按照显示的步骤操作。
  • 要提交更复杂的反馈,请创建一个 Bugzilla ticket:

    1. 进入 Bugzilla 网站。
    2. 在 Component 中选择 Documentation
    3. Description 中输入您要提供的信息。包括文档相关部分的链接。
    4. Submit Bug

第 1 章 RHEL 安全强化概述

由于日益依赖强大的网络计算机来帮助经营业务并跟踪个人信息,整个行业围绕网络和计算机安全性建立起来。企业已请求安全专家的知识和技能正确审核系统和定制解决方案,以满足组织的运营要求。因为大多数机构动态程度更高,所以相关员工会在本地和远程访问关键的公司 IT 资源,因此对安全计算环境的需求也随之变得更高。

不幸的是,很多机构以及个人用户都认为安全性是自带的。用户通常会更专注于系统的功能、生产率、方便性、易用性。而对安全的考虑通常是在发生了系统被入侵后才进行。在将站点连接到不可信网络(如互联网)之前,采取正确的措施是抵御入侵尝试的有效方法。

1.1. 什么是计算机安全性?

计算机安全性是一个涵盖计算和信息处理范围的一般术语。依靠计算机系统和网络进行日常业务交易和访问重要信息的行业将数据视为其整体资产的重要组成部分。些术语和指标已进入我们的日常业务词汇,如总拥有成本(TCO)、投资回报(ROI)和服务质量(QoS)。借助这些指标,行业可以将数据完整性和高可用性(HA)等因素作为规划和流程管理成本的一部分进行计算。在电子商业等行业中,数据的可用性和可信赖性意味着成功和失败之间的区别。

1.2. 标准化安全

每个行业的企业依赖制定标准机构(如美国医疗协会(AMA)或电气与电子工程师协会(IEEE))设定的法规和规则。对于信息安全性,同样如此。许多安全顾问和供应商都同意了称为 CIA 或机密性、完整性和可用性的标准安全模型。这种三层模式是普遍认可的组件,用于评估敏感信息的风险和建立安全策略。下面进一步详细描述了 CIA 模型:

  • 机密性 - 敏感信息必须只对一组预定义的个人可用。应限制未经授权的信息传输和使用。例如,信息的机密性确保了客户的个人或财务信息不会被未经授权的人出于恶意目的(如身份盗窃或信用欺诈)获得。
  • 完整性 - 不应以导致信息不完整或不正确的方式更改信息。未授权用户应受限于修改或销毁敏感信息的能力。
  • 可用性 - 授权用户可随时根据需要访问信息。可用性是一种保证,即可以按照商定的频率和及时性获得信息。这通常以百分比来衡量,并同意在网络服务提供商及其企业客户的服务级别协议(SLA)中正式制定。

1.3. 加密软件和认证

红帽企业 Linux 接受多项安全认证,如 FIPS 140-2 或通用标准 (CC),以确保遵循行业最佳实践。

RHEL 8 核心加密组件知识库文章概述了 Red Hat Enterprise Linux 8 核心加密组件,记录哪些组件、选择方式、如何集成到操作系统中、它们如何支持硬件安全模块和智能卡以及如何加密认证适用于它们。

1.4. 安全控制

计算机安全性通常分为三种不同的主要类别,通常称为 控制

  • 物理
  • 技术
  • 管理

这三大类别定义了适当安全实施的主要目标是。这些控件内是子类别,进一步详细说明控件及其实施方法。

1.4.1. 物理控制

物理控制是在定义的结构中实施安全措施,用于阻止或阻止对敏感材料进行未经授权的访问。物理控制示例如下:

  • 闭路监控摄像机
  • 运动或热报警系统
  • 安全保护
  • 照片 ID
  • 金属门锁定
  • 生物统计学(包括指纹、声音、脸部、虹膜、笔迹和其他用于识别个人的自动方法)。

1.4.2. 技术控制

技术控制使用技术作为控制物理结构和网络上敏感数据访问和使用的基础。技术控制范围很广,包含如下技术:

  • 加密
  • 智能卡
  • 网络验证
  • 访问控制
  • 文件完整性审核软件

1.4.3. 管理控制

管理控制确定了安全的人为因素。它们涉及机构内所有级别的人员,并确定哪些用户有权访问哪些资源和信息,例如:

  • 培训并认知
  • 灾难和恢复计划
  • 人员与隔离策略
  • 人员注册和核算

1.5. 漏洞评估

根据时间、资源和动机,攻击者几乎可以进入任何系统。当前提供的所有安全程序和技术都无法保证所有系统完全不受入侵。路由器有助于保护到互联网的网关的安全。防火墙有助于保护网络边缘。虚拟专用网络在加密流中安全地传递数据。入侵检测系统提醒您进行恶意活动.但是,这些技术能否成功取决于多个变量,包括:

  • 负责配置、监控和维护技术的人员的专业技能.
  • 能够快速高效地修补和更新服务及内核。
  • 负责人员在网络上时刻保持警觉的能力。

考虑到数据系统和技术的动态状态,保护企业资源可能非常复杂。由于这种复杂性,通常很难为所有系统找到专家资源。尽管在信息安全的许多领域具有丰富的人员知识仍然有可能,但很难保留在多个主题领域的专家。这主要是因为信息安全的每个主题领域都需要持续关注和关注。信息安全并不存在。

漏洞评估是对您的网络和系统安全性的内部审计;其结果表明您的网络的机密性、完整性和可用性。通常,漏洞评估从分析阶段开始,在该阶段收集有关目标系统和资源的重要数据。此阶段会导致系统就绪阶段,将基本检查所有已知的漏洞目标。报告阶段结束,调查结果分为高、中度和低风险类别;并讨论提高目标安全(或降低漏洞风险)的方法。

如果您要对家进行漏洞评估,您可能会检查家中的每个门,看看它们是否被关闭和锁定。您还要检查每个窗口,确保它们完全关闭且正确。同样的概念也适用于系统、网络和电子数据。恶意用户是您的数据的无处不在和篡改。然后,您可以专注于自己的工具、精力和措施来应对恶意用户。

1.5.1. 定义评估并测试

漏洞调查可分为两种类型:outside looking ininside looking around

当进行外部漏洞评估时,您会试图从外部破坏您的系统。这可能使您以一个外部攻击者的角度来对安全进行考虑。您会看到攻击者可以看到的内容 - 可公开路由的 IP 地址、您的 DMZ 系统、防火墙的外部接口等等。DMZ 代表"非军事区",对应一个计算机或小子网络,该网络位于可信内部网络(如公司专用 LAN)与不可信外部网络(如公共互联网)之间。通常,DMZ 包含 Internet 流量可访问的设备,如 Web(HTTP)服务器、FTP 服务器、SMTP(电子邮件)服务器和 DNS 服务器。

当您进行内部漏洞评估时,您处于优势地位,因为您是内部的,而且您的状态已提升为可信。这是您看到的地方,并且您的同事已经登录到您的系统。您会看到打印服务器、文件服务器、数据库和其他资源。

这两种类型的漏洞评估会有分大区别。作为内部公司,为您提供比外部更多的特权。在大多数机构中,安全性被配置为把入侵者挡在外部。确保组织内部几乎很少的操作(如部门防火墙、用户级访问控制和内部资源的身份验证程序)。通常,内部查看时会有更多资源,因为大多数系统都是公司内部的系统。一旦您位于公司以外,您的状态就不被信任。外部可用的系统和资源通常非常受限。

漏洞评估和渗透测试之间是有区别的。可将漏洞评估作为入渗透试的第一步。从评估中获得的信息用于测试。评估会检查漏洞和潜在漏洞,而渗透测试实际上会尝试利用发现。

设计网络基础结构是一个动态过程。安全性信息和物理安全是动态的。执行评估会显示一个概述,它可能会报告假的正状态和假的负状态。假的正状态代表,攻击发现安全漏洞,但这些漏洞实际并不存在。假的负状态代表,没有发现存在的安全漏洞。

安全管理员的所起到的效果取决于使用的工具及自己所具有的知识。使用目前任何一个评估工具对您的系统运行,几乎可以保证会有一些假的正状态。无论是因为程序错误还是用户错误,其结果都是相同的。工具可能会发现假的正状态,但更严重的是假的负状态。

现在,已定义了漏洞评估与中路测试之间的差异,请仔细检查评估结果,然后先仔细检查插入性测试,作为您最新最佳实践方法的一部分。

警告

不要尝试在生产环境中利用漏洞。这样做会对您的系统和网络的生产率效率造成负面影响。

以下列表将检查执行漏洞的一些好处。

  • 树立主动关注信息安全的意识。
  • 在攻击这发现潜在的漏洞之前,发现潜在的漏洞。
  • 使系统保持最新,并应用了补丁程序。
  • 在开发专业人士方面促进增长和协助。
  • 中止商业损失和负面的公共形象。

1.5.2. 建立漏洞评估方法

为了协助选择用于漏洞评估的工具,建立漏洞评估方法很有帮助。遗憾的是,目前还没有预定义或行业批准的方法;但是,常识和最佳实践可以作为足够的指南。

目标是什么?我们是在看一台服务器,还是在看我们的整个网络和网络内的一切?我们是外部还是内部的?这些问题的答案非常重要,因为它们不仅有助于确定要选择的工具,而且有助于确定它们的使用方式。

要了解更多有关建立方法的信息,请参阅以下网站:

1.5.3. 漏洞评估工具

评估可以从使用某种形式的信息收集工具开始。评估整个网络时,请先映射布局,以查找正在运行的主机。定位后,单独检查每个主机。专注于这些主机需要另外一组工具。了解使用哪些工具可能是查找漏洞的最关键步骤。

以下工具只是可用工具中的一些选择:

  • nmap 是一个流行工具,可用于查找主机系统和这些系统上的开放端口。要从 AppStream 存储库安装 Nmap,以 root 用户身份 输入 yum install nmap 命令。如需更多信息,请参阅 nmap(1) 手册页。
  • OpenSCAP套件的工具,如oscap命令行工具和scap-workbench图形工具,提供了一个完全自动化的合规性审计。如需更多信息,请参阅扫描系统以了解安全合规和漏洞
  • 高级入侵检测环境(Advanced Intrusion Detection Environment,简称 AIDE)是一个实用工具,它可以创建系统上的文件数据库,然后利用该数据库来确保文件的完整性,并检测系统入侵。如需更多信息,请参阅使用 AIDE 检查完整性

1.6. 安全隐患

1.6.1. 网络安全隐患

配置网络的以下方面时的错误做法可能会增加攻击的风险。

不安全的构架

一个错误配置的网络是未授权用户的主要入口点。让一个基于信任的、开放的本地网络暴露在高度不安全的互联网上,就像让一扇门在一个犯罪猖獗的社区里敞开一样--在一段时间内可能不会发生任何事情,但终究会有人利用这个机会。

广播网络

系统管理员往往无法意识到网络硬件在其安全计划中的重要性。简单硬件(如集线器和路由器)依赖于广播或非交换原则;也就是说,每当节点通过网络将数据传输到接收节点时,集线器或路由器会发送数据包广播,直到接收节点接收和处理数据。此方法最易受地址解析协议(ARP)或介质访问控制(MAC)地址欺骗,它受到本地主机上的入侵者和未经授权的用户欺骗。

中央服务器

另一个潜在的网络弱点是集中式的计算环境。许多企业常用的降低成本措施是将所有服务整合到一台功能强大的机器上。这很方便,因为管理和成本比多服务器配置要低得多。但是,集中式服务器在网络上引入单点故障。如果中央服务器泄露,可能会导致网络完全不可用或更加糟糕,容易发生数据操作或失窃。在这些情况下,中央服务器成为允许访问整个网络的开放门。

1.6.2. 服务器安全隐患

服务器安全性与网络安全性同样重要,因为服务器通常包含大量组织的重要信息。如果服务器被入侵,则所有内容可能变得可供攻击者窃取或随意操作。以下小节详细介绍了一些主要问题。

未使用的服务和开放端口

Red Hat Enterprise Linux 8 的完整安装包含超过 1000 个应用程序和库软件包。但是,大多数服务器管理员不选择在发行版中安装每一个软件包,而更喜欢安装软件包的基本安装,包括多个服务器应用。

系统管理员经常出现的情况是,安装操作系统时没有注意到底安装了哪些程序。这可能有问题,因为可能会安装不需要的服务,使用默认设置进行配置,并且可能开启。这可能导致不需要的服务(如 Telnet、DHCP 或 DNS)在服务器或工作站上运行,而管理员未意识到它,这可能会给服务器造成不必要的流量,甚至造成进入系统的潜在通途,导致攻击者进入系统。

未应用补丁的服务

默认安装中包含的大多数服务器应用程序都是经过全面测试的可靠、经过全面测试的软件。多年来一直在生产环境中使用,其代码得到了全面优化,发现并修复了许多漏洞。

然而,没有像完美软件这样的事情,也总有进一步解决的空间。较新的软件通常不会象预期的一样严格测试,因为它最近才开始在生产环境中使用,或者可能不像其它服务器软件一样流行。

开发人员和系统管理员通常在服务器应用程序中找到可利用的错误,并在错误跟踪和安全相关网站上发布相关信息,如 Bugtraq 邮件列表(http://www.securityfocus.com)或计算机应急响应团队(CERT)网站(http://www.cert.org)。虽然这些机制是提醒社区了解安全隐患的有效方法,但效果取决于系统管理员是否立即对系统进行了补丁。这一点尤为正确,因为攻击者可以访问这些相同的漏洞跟踪服务,并将在可能时利用信息破解未修补的系统。良好的系统管理需要保持警惕,不断地跟踪程序漏洞,并进行适当的系统维护,以确保更安全的计算环境

管理员疏忽

管理员如果没有对系统进行补丁,则会对服务器安全性造成最大的威胁。这既适用于没有经验的管理者,也适用于过于自信或积极进取的管理者。

有些管理员没有给服务器和工作站打补丁,而有些管理员则没有观察系统内核或网络流量的日志消息。另一个常见错误是服务的默认密码或密钥没有改变。例如,一些数据库具有默认的管理密码,因为数据库开发人员假定系统管理员在安装后立即更改这些密码。如果数据库管理员没有修改这个密码,即使是没有经验的破解者也可以使用一个广为人知的默认密码来获得数据库的管理权限。这些只是几个例子,说明不注意管理会导致服务器被入侵。

本质上不安全的服务

如果选择的网络服务本身就不安全,即使是最警惕的组织也会成为漏洞的受害者。例如,有许多服务是在假设它们是在受信任的网络上使用的情况下开发的;然而,一旦服务在互联网上变得可用这一假设就失效了(互联网本身就是不受信任的)。

一个不安全的网络服务是那些需要未加密用户名和密码进行验证的服务。Telnet 和 FTP 是两个这样的服务。如果数据包嗅探软件监测到远程用户和这种服务之间的流量,用户名和密码很容易被截获。

从本质上讲,这类服务也更容易成为安全行业所说的中间人攻击的猎物。在这种类型的攻击中,攻击者通过欺骗网络上被破解的名称服务器指向他的机器而不是目标服务器来重定向网络流量。旦有人打开到服务器的远程会话,攻击者的计算机将充当不可见的渠道,在远程服务和不指定用户捕获信息之间保持静默。这样,攻击者可以在没有服务器或者用户的情况下收集管理密码和原始数据。

另一类不安全的服务包括网络文件系统和信息服务,如NFS或NIS,它们是明确为局域网使用而开发的,但不幸的是,它们被扩展到包括广域网(为远程用户)。默认情况下,NFS 没有配置任何验证或安全机制以防止供节者挂载 NFS 共享并访问包含的任何内容。NIS 还具有网络中的每个计算机都必须在纯文本 ASCII 或 DBM(ASCII 派生)数据库中识别的重要信息,包括密码和文件权限。获得这个数据库访问权限的攻击者可访问网络中的每个用户帐户,包括管理员的帐户。

默认情况下,Red Hat Enterprise Linux 8 会在关闭所有这些服务的情况下发布。但是,由于管理员通常发现自己强制使用这些服务,因此仔细的配置非常重要。

1.6.3. 对工作站和主目录 PC 安全性的威胁

工作站和家庭 PC 可能不会受到网络或服务器的攻击,而是因为它们通常包含敏感数据,如信用卡信息,它们都是系统攻击者的目标。工作站也可以在没有用户知识的情况下使用,攻击者将工作站用作协调攻击中的"bot"计算机。因此,了解工作站的漏洞可让用户避免重新安装操作系统的麻烦,或者更糟糕地从数据失窃中恢复。

错误密码

错误密码是攻击者获得系统访问权限最简单的方法之一。

存在安全漏洞的客户端应用程序

虽然管理员可能拥有一个完全安全且修补的服务器,但这并不表示远程用户在访问时是安全的。例如,如果服务器通过公共网络提供 Telnet 或 FTP 服务,攻击者可以在通过网络时捕获纯文本用户名和密码,然后使用帐户信息来访问远程用户的工作站。

即使使用安全协议(如 SSH),如果远程用户不更新其客户端应用,它们也可能会受到某些攻击。例如,SSH 协议版本 1 客户端容易遭受恶意 SSH 服务器的 X 转发攻击。连接到服务器后,攻击者可以静默捕获客户端通过网络执行的任何击键操作和鼠标单击操作。这个问题已在 SSH 版本 2 协议中解决,但用户需要跟踪哪些应用程序有此类漏洞并根据需要进行更新。

1.7. 常见漏洞和攻击

表 1.1 “常见漏洞” 详细说明入侵者用于访问组织网络资源的一些最常见的漏洞和入口点。这些常见漏洞的关键在于解释如何执行它们以及管理员如何正确地保护其网络免受此类攻击。

表 1.1. 常见漏洞

漏洞描述备注

null 或 default 密码

将管理密码留空,或使用产品供应商设置的默认密码.这在路由器和防火墙等硬件中最常见,但一些在 Linux 上运行的服务也可以包含默认的管理员密码(虽然 Red Hat Enterprise Linux 8 不随同提供)。

通常与网络硬件(如路由器、防火墙、VPN 和网络附加存储(NAS)设备)相关联。

在很多传统操作系统中常见,尤其是捆绑服务(如 UNIX 和 Windows)的操作系统。

管理员有时会在崩溃中创建特权用户帐户,并将密码保留为空,从而为发现该帐户的恶意用户创建完美入口点。

默认共享密钥

有时,安全服务会打包用于开发或评估测试目的的默认安全密钥。如果这些密钥保持不变,并放置在互联网上的生产环境中,则具有相同默认密钥的所有用户都可以访问该共享密钥资源及其包含的任何敏感信息

最常在无线接入点和预配置的安全服务器设备中。

IP 欺骗

远程计算机充当本地网络上的节点,找到您的服务器的漏洞,并安装一个后门程序或 Trojan horse 来控制您的网络资源。

欺骗比较困难,因为它涉及到攻击者预测 TCP/IP 序列号以协调与目标系统连接的攻击者,但有多种工具都可用于协助攻击者执行此类漏洞。

具体取决于使用基于源的身份验证技术的目标系统运行服务 (如rsh、telnet、FTP 等),与 ssh 或 SSL/TLS 中使用的其他形式的加密身份验证相比,不建议这样做。

Seavesdropping

通过窃听两个节点之间的连接,在网络上的两个活跃节点之间传递数据。

这种类型的攻击主要适用于 Telnet、FTP 和 HTTP 传输等纯文本传输协议。

远程攻击者必须有权访问 LAN 上的已入侵系统才能执行此类攻击;通常攻击者已使用主动攻击(如 IP 欺骗或中间人)破坏了 LAN 上的系统。

安全措施包括带有加密密钥交换的服务、一次性密码或加密身份验证以防止密码嗅探;还建议在传输期间进行强大的加密。

服务漏洞

攻击者发现在互联网上运行的服务有缺陷或漏洞;通过此漏洞,攻击者破坏整个系统以及可能保存的任何数据,并可能破坏网络中的其他系统。

基于 HTTP 的服务(如 CGI)容易受到远程命令执行甚至交互式 shell 访问的影响。即使 HTTP 服务作为非特权用户(如"nobody")运行,可以读取配置文件和网络映射等信息,或者攻击者也可以启动拒绝服务攻击,从而排空系统资源或使其无法被其他用户访问。

服务有时可能会有在开发和测试过程中没有被注意的漏洞;这些漏洞(如缓冲区溢出,攻击者会使用填充应用内存缓冲区的任意值使服务崩溃,从而给予攻击者一个交互式命令提示,他们可以从中执行任意命令)可以为攻击者提供完整的管理控制。

管理员应确保服务不以 root 用户身份运行,并且应保持对来自供应商或安全组织(如 CERT 和 CVE)的应用程序的补丁和勘误表更新。

应用程序漏洞

攻击者在桌面和工作站应用程序(如电子邮件客户端)中发现故障,执行任意代码,为将来的入侵或崩溃系统而模仿 Trojan 马车。如果被入侵的工作站在网络其余部分上具有管理特权,则可能会进一步利用。

工作站和桌面更易被利用,因为工作者不具备防止或检测到威胁的专业知识或经验;必须告知个人在安装未授权软件或开放非请求电子邮件附件时所承担的风险。

可以实施保护,使电子邮件客户端软件不自动打开或执行附件。此外,使用红帽网络自动更新工作站软件;或其他系统管理服务可以减轻多套安全部署的负担。

拒绝服务(DoS)攻击

攻击者或攻击者组通过向目标主机(服务器、路由器或工作站)发送未经授权的数据包,针对组织的网络或服务器资源进行协调。这会强制资源对合法用户不可用。

美国报告的最新 DoS 问题单在 2000 年发生。使用具有高带宽连接的几个具有高带宽连接的系统作为僵停或重定向广播节点,一个协调的 ping 攻击使一些高流量商业和政府站点不可用。

源数据包通常会伪造(以及重播),从而使调查攻击的真正来源变得困难。

使用 iptables 和 Network Intrusion Detection 系统(如 snort)帮助管理员跟踪并防止分布式 DoS 攻击,从而在入口过滤(IETF rfc2267)中进行入口过滤(IETF rfc2267)。

第 2 章 在安装过程中保护 RHEL

安全性甚至始于您开始安装红帽企业 Linux 之前。从开始便安全地配置您的系统,以后更轻松地实施额外的安全设置。

2.1. BIOS 和 UEFI 安全

对 BIOS(或 BIOS 等效)和启动加载程序的密码保护可防止对系统具有物理访问权限的未授权用户使用可移动介质启动,或通过单用户模式获得 root 权限。您为防止此类攻击而需要采取的安全措施取决于工作站中信息和计算机位置的敏感程度。

例如,如果一台计算机在交易展示中使用并且不包含敏感信息,那么防止此类攻击可能并不重要。但是,如果员工的笔记本电脑中对公司网络的未加密 SSH 密钥仍保持不变,则可能导致整个公司出现重大安全漏洞。

但是,如果工作站位于只有授权人或可信人员有权访问的地方,则可能不需要保护 BIOS 或引导加载程序。

2.1.1. BIOS 密码

密码保护计算机 BIOS 的两个主要原因是[1]:

  1. 防止对 BIOS 设置的更改 - 如果入侵者可以访问 BIOS,他们可以将其设置为从 CD-ROM 或闪存驱动器引导。这使得他们能够进入救援模式或单用户模式,从而让他们可以在系统上启动任意进程或复制敏感数据。
  2. 防止系统启动 - 一些 BIOS 允许对引导过程进行密码保护。激活后,攻击者必须在 BIOS 启动加载器启动前输入密码。

由于设置 BIOS 密码的方法因计算机制造商而异,因此请查阅计算机手册了解具体说明。

如果您忘记 BIOS 密码,可以通过主板上的跳转器重置,也可以通过断开 CMOS 电池来重置。因此,最好尽可能锁定计算机案例。但是,在尝试断开 CMOS 电池之前,请查阅计算机或主板的手册。

2.1.2. 非基于 BIOS 的系统安全性

其他系统和架构使用不同的程序来执行大致相当于 x86 系统上 BIOS 的低级别任务。例如,统一可扩展固件接口 (UEFI)shell。

有关保护类似 BIOS 程序的密码的说明,请查看制造商的说明。

2.2. 磁盘分区

红帽建议为 /boot 、/home、/tmp /var/tmp / 目录创建单独的分区。

/boot
这个分区是系统在启动过程中读取的第一个分区。用于将系统引导至 Red Hat Enterprise Linux 8 的引导装载程序和内核镜像保存在这个分区中。此分区不应加密。如果此分区包含在 / 中,并且该分区已加密或者不可用,那么您的系统将无法引导。
/home
当用户数据(/home)存储在 / 而不是独立分区中时,分区可能会填满,从而导致操作系统不稳定。另外,当将您的系统升级到 Red Hat Enterprise Linux 8 的下一个版本时,当您可以在 /home 分区中保存数据时会更加容易,因为在安装过程中不会被覆盖。如果 root 分区(/)损坏,则您的数据将永久丢失。通过使用单独的分区,可以稍微多一点地保护数据丢失。您还可以将此分区作为频繁备份的目标。
/tmp/var/tmp/
/tmp/var/tmp/ 目录都是用来存储不需要长期存储的数据。但是,如果大量数据填充了其中一个目录,则它可以消耗您的所有存储空间。如果发生这种情况,且这些目录存储在 / 中,则您的系统可能会变得不稳定并崩溃。因此,将这些目录移动到自己的分区中是一个不错的想法。
注意

在安装过程中,您可以选择加密分区。您必须提供密码短语。此密语充当解锁批量加密密钥的密钥,该密钥用于保护分区的数据。

2.3. 在安装过程中限制网络连接

安装 Red Hat Enterprise Linux 8 时,安装介质代表系统在特定时间的快照。因此,它可能不是最新的安全修复程序,而且可能会受到仅在安装介质提供的系统发布后解决的某些问题的影响。

安装有潜在漏洞的操作系统时,始终只限制对最接近的必要网络区域的影响。最安全的选择是"无网络"区域,这意味着在安装过程中保持计算机断开连接。在某些情况下,LAN 或 Intranet 连接就足够了,而互联网连接的风险最大。要遵循最佳安全实践,请在从网络安装 Red Hat Enterprise Linux 8 时选择带有您的软件仓库的最接近的区域。

2.4. 安装所需的最小软件包

最好仅安装您将使用的软件包,因为计算机上的每一款软件可能包含漏洞。如果您要从 DVD 介质安装,请仔细选择要在安装过程中安装的软件包。如果您发现需要其他软件包,您可在以后将其添加到系统中。

2.5. 安装后流程

以下步骤是在安装 Red Hat Enterprise Linux 8 后立即执行的安全相关步骤。

  • 更新您的系统。以 root 用户身份输入以下命令:

    # yum update
  • 尽管随着安装 Red Hat Enterprise Linux 会自动启用防火墙服务 firewalld,但在某些情况下,它可能会明确禁用,例如在 kickstart 配置中。在这种情况下,建议考虑重新启用防火墙。

    要启动 firewalld,以 root 用户身份输入以下命令:

    # systemctl start firewalld
    # systemctl enable firewalld
  • 要提高安全性,禁用您不需要的服务。例如,如果您的计算机上没有安装打印机,使用以下命令禁用 cups 服务:

    # systemctl disable cups

    要查看活跃的服务,请输入以下命令:

    $ systemctl list-units | grep service


[1] 由于系统 BIOS 在制造商之间有所不同,一些可能不支持任一类型的密码保护,另一些则可能支持一种类型,但不支持另一种类型。

第 3 章 安装启用了 FIPS 模式的 RHEL 8 系统

要启用联邦信息处理标准(FIPS)公共 140-2 强制的加密模块,您必须在 FIPS 模式下操作 RHEL 8。

您可以通过以下方法达到此目的:

  • 以 FIPS 模式开始安装。
  • 安装后将系统切换到 FIPS 模式。

为避免重新生成并重新评估与转换已部署的系统相关的系统合规性,红帽建议以 FIPS 模式开始安装。

3.1. 联邦信息处理标准(FIPS)

联邦信息处理标准(FIPS)出版物 140-2 是美国开发的计算机安全标准。政府和行业工作组验证加密模块的质量。请参阅NIST Computer 安全资源中心上的官方 FIPS 出版物。

FIPS 140-2 标准确保加密工具正确实施了它们的算法。其中一个机制是运行时自我检查。如需了解更多与 FIPS 标准相关的信息,请参阅 FIPS PUB 140-2 的完整 FIPS 140-2 标准。

要了解合规要求,请参阅红帽政府标准页面

3.2. 使用启用了 FIPS 模式安装系统

要启用加密模块自我检查联邦信息处理标准(FIPS)公共 140-2 强制的加密模块,请在系统安装过程中启用 FIPS 模式。

重要

红帽建议安装启用了 FIPS 模式的 Red Hat Enterprise Linux 8,而不是以后启用 FIPS 模式。在安装过程中启用 FIPS 模式可确保系统生成所有使用 FIPS 批准算法的密钥和持续监控测试。

流程

  • 在系统安装期间,将 fips=1 选项添加到内核命令行。

    在软件选择阶段,请勿安装任何第三方软件。

安装后,系统会自动以 FIPS 模式启动。

验证

  • 系统启动后,检查是否启用了 FIPS 模式:

    $ fips-mode-setup --check
    FIPS mode is enabled.

3.3. 其它资源

第 4 章 使用系统范围的加密策略

Crypto 策略是一个系统组件,它可配置核心加密子系统,覆盖 TLS、IPSec、SSH、DNSSEC 和 Kerberos 协议。它提供一组小策略,管理员可以选择这些策略。

4.1. 系统范围的加密策略

设置系统范围的策略后,RHEL 中的应用程序会紧随其后,并拒绝使用不符合该策略的算法和协议,除非您明确请求该应用程序这样做。也就是说,该策略适用于应用使用系统提供的配置运行时的默认行为,但在需要时您可以覆盖它。

Red Hat Enterprise Linux 8 包括以下策略级别:

DEFAULT

默认的系统范围加密策略级别为当前威胁模型提供了安全设置。它允许 TLS 1.2 和 1.3 协议,以及 IKEv2 和 SSH2 协议。如果 RSA 密钥和 Diffie-Hellman 参数至少是 2048 位,则可以接受它们。

LEGACY

此策略确保了与红帽企业 Linux 5 及更早版本的最大兼容性;由于攻击面的增加,它的安全性较低。除了 DEFAULT 级别算法和协议外,它还包括对 TLS 1.0 和 1.1 协议的支持。允许算法 DSA、3DES 和 RC4,如果它们至少有 1023 位,则接受 RSA 密钥和 Diffie-Hellman 参数。

未来

保守的安全级别,可以防止任何近期的攻击。这个级别不允许在签名算法中使用 SHA-1。如果 RSA 密钥和 Diffie-Hellman 参数至少是 3072 位,则可以接受它们。

FIPS

符合 FIPS 140-2 要求的策略级别。fips-mode-setup 工具在内部使用,该工具将 RHEL 系统切换到 FIPS 模式。

红帽不断调整所有策略级别,以便除了使用 ACY 策略时,所有库都提供安全默认值。尽管 criACY 配置集不提供安全默认值,但它不包括任何易利用的算法。因此,任何提供的策略中已启用的算法集合或可接受的密钥大小在 Red Hat Enterprise Linux 8 的生命周期内可能会改变。

此类变更反映了新的安全标准和新的安全研究。如果您必须确保在 Red Hat Enterprise Linux 8 的整个生命周期内与特定系统互操作,则对于与该系统交互的组件,您不应该选择使用加密策略。

重要

因为客户门户网站 API 中的证书使用的加密密钥不满足 FUTURE 系统范围的加密策略的要求,所以 redhat-support-tool 程序目前无法使用这个策略级别。

要临时解决这个问题,在连接到客户门户网站 API 时使用 DEFAULT 加密策略。

注意

只有应用支持时,策略级别中描述的特定算法和密码才可用。

管理加密策略的工具

要查看或更改当前的系统范围的加密策略,请使用 update-crypto-policies 工具,例如:

$ update-crypto-policies --show
DEFAULT
# update-crypto-policies --set FUTURE
Setting system policy to FUTURE

要确保应用修改加密策略,重启系统。

强大的加密默认方法是删除不安全的密码套件和协议

以下列表包含从 Red Hat Enterprise Linux 8 核心加密库中删除的密码套件和协议。它们不存在于源中,或者其支持在构建期间被禁用,因此应用程序无法使用它们。

  • DES(自 RHEL 7 开始)
  • 所有导出评级密码套件(自 RHEL 7 开始)
  • 签名中的 MD5(自 RHEL 7 开始)
  • SSLv2(自 RHEL 7 开始)
  • SSLv3(自 RHEL 8 开始)
  • 所有 ECC 曲线 < 224 位(自 RHEL 6 开始)
  • 所有二进制字段 ECC curves(自 RHEL 6 开始)

在所有策略级别禁用密码套件和协议

在所有 crypto 策略级别中禁用了以下密码套件和协议。它们只能通过明确配置各个应用来启用。

  • DH 带有参数 < 1024 位
  • RSA 带有密钥大小 < 1024 位
  • Camellia
  • ARIA
  • SEED
  • IDEA
  • 仅完整性密码套件
  • 使用 SHA-384 HMAC 的 TLS CBC 模式密码组合
  • AES-CCM8
  • 所有 ECC curves 与 TLS 1.3 不兼容,包括 secp256k1
  • IKEv1(自 RHEL 8 开始)

在 crypto-policies 级别启用密码套件和协议

下表显示了在所有四个加密策略级别中启用的密码套件和协议。

 LEGACYDEFAULTFIPS未来

IKEv1

3DES

RC4

DH

Min. 1024 位

2048 位

2048 位

Min. 3072 位

RSA

Min. 1024 位

2048 位

2048 位

Min. 3072 位

DSA

TLS v1.0

TLS v1.1

数字签名中的 SHA-1

CBC 模式密码

[a]

带有键为 256 位的对称密码

证书中的 SHA-1 和 SHA-224 签名

[a] 为 TLS 禁用 CBC 密码。在非 TLS 场景中,AES-128-CBC 被禁用,但启用了 AES-256-CBC。要禁用 also AES-256-CBC,请应用自定义子策略。

其它资源

  • update-crypto-policies(8) man page

4.2. 将系统范围的加密策略切换到与早期版本兼容的模式

Red Hat Enterprise Linux 8 中的默认系统范围加密策略不允许使用较旧的不安全协议进行通信。对于需要与 Red Hat Enterprise Linux 5 兼容且在某些情况下也与早期版本兼容的环境,可以使用不太安全 的规范级别

警告

切换到 cri ACY 策略级别会导致系统和应用程序的安全性较低。

流程

  1. 要将系统范围的加密策略切换到 cri ACY 级别,以 root 用户身份输入以下命令:

    # update-crypto-policies --set LEGACY
    Setting system policy to LEGACY

其它资源

  • 有关可用加密策略级别列表,请参阅 update-crypto-policies(8)man page。

4.3. 将系统切换到 FIPS 模式

系统范围的加密策略包含一个策略级别,允许加密模块根据联邦信息处理标准(FIPS)公共 140-2 的要求进行自我检查。fips-mode-setup 工具在内部启用或禁用 FIPS 模式,使用 FIPS 系统范围的加密策略级别。

重要

红帽建议安装启用了 FIPS 模式的 Red Hat Enterprise Linux 8,而不是以后启用 FIPS 模式。在安装过程中启用 FIPS 模式可确保系统生成所有使用 FIPS 批准算法的密钥和持续监控测试。

流程

  1. 在 RHEL 8 中将系统切换到 FIPS 模式:

    # fips-mode-setup --enable
    Setting system policy to FIPS
    FIPS mode will be enabled.
    Please reboot the system for the setting to take effect.
  2. 重启您的系统以允许内核切换到 FIPS 模式:

    # reboot

验证

  1. 重启后,您可以检查 FIPS 模式的当前状态:

    # fips-mode-setup --check
    FIPS mode is enabled.

其它资源

4.4. 在容器中启用 FIPS 模式

在 RHEL 8.3 及更新的版本中,您不需要根据联邦信息处理标准(FIPS)公共 140-2 的要求手动启用加密模块。在启用了 FIPS 模式的系统中,podman 工具会自动将容器配置为 FIPS 模式。

注意

在 RHEL 8 中,fips-mode-setup 命令无法在容器中正常工作,在这种情况下无法用来启用或检查 FIPS 模式。

4.4.1. 在 RHEL 8.2 中的容器中启用 FIPS 模式

在 RHEL 8.2 及更新的版本中,您可以使用容器中的单个命令手动将容器切换到 FIPS 模式。请注意,主机系统必须处于 FIPS 模式,请参阅将系统切换到 FIPS 模式

# mount --bind /usr/share/crypto-policies/back-ends/FIPS /etc/crypto-policies/back-ends

4.4.2. 在 RHEL 8.1 及更早版本的容器中启用 FIPS 模式

在 RHEL 8.1 及更早版本中,要根据联邦信息处理标准(FIPS)公共 140-2 的要求在容器中启用加密模块自我检查:

先决条件

流程

  1. /etc/system-fips 文件挂载到主机上的容器上。
  2. 在容器中设置 FIPS 加密策略级别:

    $ update-crypto-policies --set FIPS

4.5. 使用与 FIPS 140-2 不兼容的加密的 RHEL 应用程序列表

红帽建议使用核心加密组件集中的库,因为它们可以保证传递所有相关的加密认证,如 FIPS 140-2,并遵循 RHEL 系统范围的加密策略。

有关 RHEL 8 核心加密组件的概述,请参阅 RHEL 8 核心加密组件文章、有关如何选择它们的信息、它们如何集成到操作系统中、它们如何支持硬件安全模块和智能卡,以及如何对它们应用加密认证。

除了下表外,在有些 RHEL 8 Z-stream 版本(如 8.1.1)中,Firefox 浏览器软件包已被更新,它们包含 NSS 加密库的单独副本。这样,红帽就希望避免在补丁版本中修复此类低级组件而造成干扰。因此,这些 Firefox 软件包不使用 FIPS 140-2 验证的模块。

表 4.1. 使用与 FIPS 140-2 不兼容的加密的 RHEL 8 应用程序列表

Application详情

freeraDIUS

RADIUS 协议使用 MD5

ghostscript

自定义加密(MD5、RC4、SHA-2、AES)来加密和解密文档

Grafana

Golang x/crypto 模块的加密实现(Ed25519、CBC、OCFB、…​)

ipxe

TLS 的加密堆栈编译到 中,但它并没有使用

libica

软件回退用于各种算法,如 RSA 和 ECDH 通过 CPACF 指令

ovmf(UEFI 固件)、Edk2、shim

完整的加密堆栈(OpenSSL 库的嵌入式副本)

perl-Digest-HMAC

HMAC, HMAC-SHA1, HMAC-MD5

perl-Digest-SHA

SHA-1, SHA-224, …​

pidgin

DES、RC4

qatengine

混合加密原语的硬件和软件实现(RSA、EC、DH、AES、…​)

samba[a]

AAS、DES、RC4

valgrind

asa, hashes[b]

[a] 从 RHEL 8.3 开始,samba 使用与 FIPS 兼容的加密。
[b] 重新实施软件硬件卸载操作,如 AES-NI。

4.6. 将应用程序从系统范围的加密策略中排除

您可以通过直接在应用程序中配置受支持的密码套件和协议来自定义应用程序使用的加密设置。

您还可以从 /etc/crypto-policies/back-ends 目录中删除与应用程序相关的符号链接,并使用自定义的加密设置替换它。此配置可防止在使用排除后端的应用程序中使用系统范围的加密策略。此外,红帽不支持此修改。

4.6.1. 选择不使用系统范围的加密策略的示例

wget

要自定义 wget 网络下载器使用的加密设置,请使用 --secure-protocol--ciphers 选项。例如:

$ wget --secure-protocol=TLSv1_1 --ciphers="SECURE128" https://example.com

如需更多信息,请参阅 wget(1) man page 中的 HTTPS(SSL/TLS)Options 部分。

curl

要指定 curl 工具使用的密码,请使用 --ciphers 选项,并提供以冒号分隔的密码列表作为值。例如:

$ curl https://example.com --ciphers '@SECLEVEL=0:DES-CBC3-SHA:RSA-DES-CBC3-SHA'

如需更多信息,请参阅 curl(1) 手册页。

Firefox

尽管您无法在 Firefox Web 浏览器中选择不使用系统范围的加密策略,但您也可以在 Firefox 的配置编辑器中进一步限制受支持的密码和 TLS 版本。在地址栏中键入 about:config 并根据需要更改 security.tls.version.min 选项的值。将 security.tls.version.min 设置为 1 允许 TLS 1.0 作为最低要求,security.tls.version.min 2 启用 TLS 1.1 等。

OpenSSH

要为您的 OpenSSH 服务器选择不使用系统范围的加密策略,请使用 /etc/sysconfig/sshd 文件中的 CRYPTO_POLICY= 变量取消注释这一行。更改后,您在 /etc/ssh/sshd_config 文件中的 Ciphers 、MAC KexAlgoritm s 和 GSSAPIKexAlgorithms 部分指定的值不会被覆盖。详情请查看 sshd_config(5) 手册页。

要为您的 OpenSSH 客户端选择不使用系统范围的加密策略,请执行以下任务之一:

  • 对于给定用户,使用 ~/.ssh/ config 文件中的用户特定配置覆盖全局 ssh_ config
  • 对于整个系统,在位于 /etc/ssh/ssh_config.d/ 目录中的置入配置文件中指定 crypto 策略,其前缀小于 50,因此它在 50-redhat.conf 文件前面加上 a .conf 后缀,如 49-crypto-policy-override.conf

详情请查看 ssh_config(5) 手册页。

其它资源

  • update-crypto-policies(8) man page

4.7. 使用策略修饰符自定义系统范围的加密策略

使用这个流程调整任何系统范围的加密策略级别或完整自定义策略的特定算法或协议。

注意

RHEL 8.2 提供了对系统范围的加密策略的自定义。

流程

  1. 签出 /etc/crypto-policies/policies/modules/ 目录:

    # cd /etc/crypto-policies/policies/modules/
  2. 为您的调整创建策略模块,例如:

    # touch MYCRYPTO1.pmod
    # touch NO-AES128.pmod
    重要

    在策略模块的文件名中使用大写字母。

  3. 在您选择的文本编辑器中打开策略模块并插入修改系统范围的加密策略的选项,例如:

    # vi MYCRYPTO1.pmod
    sha1_in_certs = 0
    min_rsa_size = 3072
    # vi NO-AES128.pmod
    cipher = -AES-128-GCM -AES-128-CCM -AES-128-CTR -AES-128-CBC
  4. 将更改保存到模块文件中。
  5. 将您的策略调整应用到 DEFAULT 系统范围的加密策略级别:

    # update-crypto-policies --set DEFAULT:MYCRYPTO1:NO-AES128
  6. 要使您的加密设置对已经运行的服务和应用程序有效,请重启系统:

    # reboot

其它资源

4.8. 通过自定义系统范围的加密策略来禁用 SHA-1

因为 SHA-1 哈希函数本身存在弱设计,并且升级加密分析使其容易受到攻击,所以 RHEL 8 默认不使用 SHA-1。然而,一些第三方应用程序(如公共签名)仍然使用 SHA-1。要在您的系统中禁用在签名算法中使用 SHA-1,您可以使用 NO-SHA1 策略 模块。

重要

NO-SHA1 策略模块仅在签名而不是其它位置禁用 SHA-1 哈希功能。特别是,NO-SHA1 模块仍然允许使用 SHA-1 和基于哈希的消息验证代码(HMAC)。这是因为 HMAC 安全属性不依赖于对应哈希函数的冲突攻击,因此 SHA-1 最近攻击 SHA-1 对 HMAC 使用 SHA-1 的影响显著降低。

注意

禁用 SHA-1 的模块包括在 RHEL 8.3 中。RHEL 8.2 提供了对系统范围的加密策略的自定义。

流程

  1. 将您的策略调整应用到 DEFAULT 系统范围的加密策略级别:

    # update-crypto-policies --set DEFAULT:NO-SHA1
  2. 要使您的加密设置对已经运行的服务和应用程序有效,请重启系统:

    # reboot

其它资源

4.9. 创建并设置自定义系统范围的加密策略

以下步骤演示了通过完整的策略文件自定义系统范围的加密策略。

注意

RHEL 8.2 提供了对系统范围的加密策略的自定义。

流程

  1. 为自定义创建策略文件:

    # cd /etc/crypto-policies/policies/
    # touch MYPOLICY.pol

    或者,从复制四个预定义策略级别之一开始:

    # cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol
  2. 在您选择的文本编辑器中使用自定义加密策略编辑文件以满足您的要求,例如:

    # vi /etc/crypto-policies/policies/MYPOLICY.pol
  3. 将系统范围的加密策略切换到自定义级别:

    # update-crypto-policies --set MYPOLICY
  4. 要使您的加密设置对已经运行的服务和应用程序有效,请重启系统:

    # reboot

其它资源

第 5 章 在系统间设置自定义加密策略

作为管理员,您可以使用 RHEL 上的 Crypto 策略系统角色快速、一致地使用 Red Hat Ansible Automation Platform 在许多不同的系统中配置自定义加密策略。

5.1. 加密策略系统角色变量和事实

在 Crypto Policies System Role playbook 中,您可以根据您的偏好和限制为 crypto 策略配置文件定义参数。

如果没有配置任何变量,系统角色不会配置系统,仅报告事实。

Crypto 策略系统角色选择的变量

crypto_policies_policy
决定系统角色应用到受管节点的加密策略级别。有关不同加密策略级别的详情,请参考系统范围的加密策略
crypto_policies_reload
如果设置为 yes,则受影响的服务目前是 ipsecbindsshd 服务,在应用加密策略后重新加载。默认值为 yes
crypto_policies_reboot_ok
如果设置为 yes,在系统角色更改 crypto 策略后需要重新启动,它会将 crypto_policies_reboot_reboot_required 设置为 yes。默认值为 no

Crypto 策略系统角色设置的事实

crypto_policies_active
列出当前选择的策略。
crypto_policies_available_policies
列出系统上的所有可用策略级别。
crypto_policies_available_modules
列出系统上的所有可用子策略模块。

5.2. 使用 Crypto 策略系统角色设置自定义加密策略

您可以使用 Crypto Policies 系统角色从单个控制节点配置大量受管节点。

先决条件

  • 访问一个或多个受管节点并获得权限,它们是您要使用 Crypto 策略系统角色配置的系统。
  • 对控制节点的访问和权限,这是 Red Hat Ansible Engine 配置其他系统的系统。

    在控制节点上:

    • 已安装 Red Hat Ansible Engine
    • 已安装 rhel-system-roles 软件包
    • 列出受管节点的清单文件。

流程

  1. 使用以下内容创建新 playbook.yml 文件:

    ---
    - hosts: all
      tasks:
      - name: Configure crypto policies
        include_role:
          name: linux-system-roles.crypto_policies
        vars:
          - crypto_policies_policy: FUTURE
          - crypto_policies_reboot_ok: true

    您可以将 FUTURE 值替换为您首选的加密策略,例如: DEFAULT、f ariaACYFIPS:OSPP

    crypto_policies_reboot_ok: true 变量会导致系统在系统角色更改 crypto 策略后重启。

    如需了解更多详细信息,请参阅Crypto 策略系统角色变量和事实

  2. 可选:验证 playbook 语法。

    # ansible-playbook --syntax-check playbook.yml
  3. 在清单文件上运行 playbook:

    # ansible-playbook -i inventory_file playbook.yml

验证

  1. 在控制节点上,创建一个名为 的另一个 playbook,例如 verify_playbook.yml:

    - hosts: all
      tasks:
     - name: Verify active crypto policy
       include_role:
         name: linux-system-roles.crypto_policies
    
     - debug:
         var: crypto_policies_active

    此 playbook 不更改系统上的任何配置,仅报告受管节点上的活跃策略。

  2. 在同一个清单文件中运行 playbook:

    # ansible-playbook -i inventory_file verify_playbook.yml
    
    TASK [debug] **************************
    ok: [host] => {
        "crypto_policies_active": "FUTURE"
    }

    "crypto_policies_active": 变量显示受管节点上活跃的策略。

5.3. 其它资源

第 6 章 将应用程序配置为通过 PKCS #11 使用加密硬件

在专用加密设备上分离机密信息的部分,如用于最终用户身份验证的智能卡和用于服务器应用程序的硬件安全模块(HSM)的加密令牌,提供了额外的安全层。在 Red Hat Enterprise Linux 8 中,通过 PKCS #11 API 对加密硬件的支持在不同的应用程序中保持一致,加密硬件上的 secret 隔离不是复杂的任务。

6.1. 通过 PKCS #11 进行加密硬件支持

PKCS #11(Public-Key Cryptography Standard)定义一个应用程序编程接口(API)来加密保存加密信息并执行加密功能的设备。这些设备称为令牌,以硬件或软件形式实施。

PKCS #11 令牌可以存储各种对象类型,包括证书、数据对象以及公共、私有或 secret 密钥。这些对象可通过 PKCS #11 URI 方案唯一识别。

PKCS #11 URI 是一种标准方法,用于根据对象属性识别 PKCS #11 模块中的特定对象。这可让您使用 URI 格式配置同一配置字符串的所有库和应用程序。

Red Hat Enterprise Linux 8 默认为智能卡提供 OpenSC PKCS #11 驱动程序。但是,硬件令牌和 HSM 可以有自己的 PKCS #11 模块,这些模块在 Red Hat Enterprise Linux 中没有对应项。您可以使用 p11-kit 工具注册这些 PKCS #11 模块,该工具充当系统中注册的智能卡驱动程序的打包程序。

要使您自己的 PKCS #11 模块在系统上正常工作,请在 /etc/pkcs11/modules/ 目录中添加新文本文件

您可以通过在 /etc/pkcs11/modules/ 目录中创建新的文本文件,将自己的 PKCS #11 模块添加到系统。例如,p11-kit 中的 OpenSC 配置文件如下所示:

$ cat /usr/share/p11-kit/modules/opensc.module
module: opensc-pkcs11.so

6.2. 使用保存在智能卡中的 SSH 密钥

Red Hat Enterprise Linux 可让您使用保存在 OpenSSH 客户端智能卡中的 RSA 和 ECDSA 密钥。使用这个步骤使用智能卡而不是使用密码启用验证。

先决条件

  • 在客户端中安装了 opensc 软件包,pcscd 服务正在运行。

流程

  1. 列出所有由 OpenSC PKCS #11 模块提供的密钥,包括其 PKCS #11 URIs,并将输出保存到 key.pub 文件:

    $ ssh-keygen -D pkcs11: > keys.pub
    $ ssh-keygen -D pkcs11:
    ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
    ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
  2. 要使用远程服务器上的智能卡(example.com)启用验证,将公钥传送到远程服务器。使用带有上一步中创建的 key.pubssh-copy-id 命令:

    $ ssh-copy-id -f -i keys.pub username@example.com
  3. 要使用在第 1 步的 ssh-keygen -D 命令输出中的 ECDSA 密钥连接到 example.com,您只能使用 URI 中的一个子集,它是您的密钥的唯一参考,例如:

    $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" example.com
    Enter PIN for 'SSH key':
    [example.com] $
  4. 您可以使用 ~/.ssh/config 文件中的同一 URI 字符串使配置持久:

    $ cat ~/.ssh/config
    IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
    $ ssh example.com
    Enter PIN for 'SSH key':
    [example.com] $

    因为 OpenSSH 使用 p11-kit-proxy wrapper 和 OpenSC PKCS #11 模块注册到 PKCS#11 Kit,所以您可以简化前面的命令:

    $ ssh -i "pkcs11:id=%01" example.com
    Enter PIN for 'SSH key':
    [example.com] $

如果您跳过 PKCS #11 URI 的 id= 部分,则 OpenSSH 会加载代理模块中可用的所有密钥。这可减少输入所需的数量:

$ ssh -i pkcs11: example.com
Enter PIN for 'SSH key':
[example.com] $

其它资源

6.3. 配置应用以使用智能卡的证书进行身份验证

  • wget网络下载器可以让您指定 PKCS #11 URI,而不是本地存储的私钥的路径,从而简化了为需要安全存储私钥和证书的任务创建脚本。例如:

    $ wget --private-key 'pkcs11:token=softhsm;id=%01;type=private?pin-value=111111' --certificate 'pkcs11:token=softhsm;id=%01;type=cert' https://example.com/

    如需更多信息,请参阅 wget(1) 手册页。

  • 指定供 curl 工具使用的 PKCS #11 URI 类似如下:

    $ curl --key 'pkcs11:token=softhsm;id=%01;type=private?pin-value=111111' --cert 'pkcs11:token=softhsm;id=%01;type=cert' https://example.com/

    如需更多信息,请参阅 curl(1) 手册页。

  • Firefox Web 浏览器会自动加载 p11-kit-proxy 模块。这意味着系统中的每个支持的智能卡都会被自动检测。要使用 TLS 客户端身份验证,不需要额外的设置,当服务器请求智能卡时,会自动使用这些密钥。

在自定义应用程序中使用 PKCS #11 URI

如果您的应用程序使用 GnuTLSNSS 库,则通过内置支持 PKCS #11 URI 来确保对 PKCS #11 的支持。此外,依赖 OpenSSL 库的应用程序还可以访问加密的硬件模块,这得益于 openssl-pkcs11 引擎。

对于需要在智能卡中使用私钥且不使用 NSSGnuTLSOpenSSL 的应用程序,请使用 p11-kit 来实现 注册 PKCS #11 模块。

其它资源

  • p11-kit(8) 手册页.

6.4. 在 Apache 中使用 HSM 保护私钥

Apache HTTP 服务器可以使用硬件安全模块(HSM)中存储的私钥,这有助于防止密钥泄漏和中间人攻击。请注意,这通常需要高性能的 HSM 用于繁忙的服务器。

对于 HTTPS 协议形式的安全通信,Apache HTTP 服务器(httpd)使用 OpenSSL 库。OpenSSL 不支持 PKCS #11 natively。要使用 HSM,您必须安装 openssl-pkcs11 软件包,它通过引擎接口提供对 PKCS #11 模块的访问。您可以使用 PKCS #11 URI 而不是常规文件名在 /etc/httpd/conf.d/ssl.conf 配置文件中指定服务器密钥和证书,例如:

SSLCertificateFile    "pkcs11:id=%01;token=softhsm;type=cert"
SSLCertificateKeyFile "pkcs11:id=%01;token=softhsm;type=private?pin-value=111111"

安装 httpd-manual 软件包以获取 Apache HTTP 服务器的完整文档,包括 TLS 配置。/etc/httpd/conf.d/ssl.conf 配置文件中的指令在 /usr/share/httpd/manual/mod_ssl.html 中有详细介绍。

6.5. 使用 HSM 在 Nginx 中保护私钥

Nginx HTTP 服务器可以使用硬件安全模块(HSM)中存储的私钥,这有助于防止密钥泄漏和中间人攻击。请注意,这通常需要高性能的 HSM 用于繁忙的服务器。

因为 Nginx 还使用 OpenSSL 进行加密操作,所以对 PKCS #11 的支持必须通过 openssl-pkcs11 引擎。nginx 目前只支持从 HSM 加载私钥,并且证书必须作为常规文件单独提供。修改 /etc/nginx/nginx.conf 配置文件的 server 部分的 ssl_certificate ssl_certificate_key 选项:

ssl_certificate     /path/to/cert.pem
ssl_certificate_key "engine:pkcs11:pkcs11:token=softhsm;id=%01;type=private?pin-value=111111";

请注意,Nginx 配置文件中 PKCS #11 URI 需要 engine:pkcs 11: 前缀。这是因为 other pkcs11 前缀引用引擎名称。

第 7 章 使用共享系统证书

共享系统证书存储支持 NSS、GnuTLS、OpenSSL 和 Java 共享检索系统证书定位符和块列表信息的默认源。默认情况下,信任存储包含 Mozilla CA 列表,包括正和负信任。系统允许更新核心 Mozilla CA 列表或选择其他证书列表。

7.1. 系统范围信任存储

在 Red Hat Enterprise Linux 中,整合的系统范围信任存储位于 /etc/pki/ca-trust//usr/share/pki/ca-trust-source/ 目录中。/usr/share/pki/ca-trust-source/ 中的信任设置的处理优先级低于 /etc/pki/ca-trust/ 中的设置。

证书文件根据安装到以下目录中的子目录来处理:

  • 对于信任定位符

    • /usr/share/pki/ca-trust-source/anchors/ or
    • /etc/pki/ca-trust/source/anchors/
  • 对于不可信证书

    • /usr/share/pki/ca-trust-source/blacklist/
    • /etc/pki/ca-trust/source/blacklist/
  • 对于扩展 BEGIN TRUSTED 文件格式的证书

    • /usr/share/pki/ca-trust-source/
    • /etc/pki/ca-trust/source/
注意

在分层加密系统中,信任定位符是一个权威实体,供其他方视为可信赖的权威实体。在 X.509 架构中,根证书是信任定位点,从中衍生了一连串信任链。要启用链验证,信任方必须首先能够访问信任定位符。

7.2. 添加新证书

要使用新的信任来源确认系统上的应用程序,请将对应的证书添加到系统范围存储中,并使用 update-ca-trust 命令。

先决条件

  • ca-certificates 软件包存在于系统中。

流程

  1. 要在简单的 PEM 或 DER 文件格式中添加证书到系统中信任的 CA 列表中,请将证书文件复制到 /usr/share/pki/ca-trust-source/anchors//etc/pki/ca-trust/source/anchors/ 目录中,例如:

    # cp ~/certificate-trust-examples/Cert-trust-test-ca.pem /usr/share/pki/ca-trust-source/anchors/
  2. 要更新系统范围的信任存储配置,请使用 update-ca-trust 命令:

    # update-ca-trust
注意

虽然 Firefox 浏览器可以使用添加的证书,但不执行 update-ca-trust,但红帽建议在 CA 更改后使用 update-ca-trust 命令。另请注意,浏览器,如 Firefox、Epiphany 或 Chromium、缓存文件,您可能需要清除浏览器的缓存或重新启动浏览器来加载当前的系统证书配置。

7.3. 管理可信系统证书

trust 命令为管理全系统共享的信任存储中的证书提供了一种方便的方式。

  • 要列出、提取、添加、删除或更改信任定位符,请使用 trust 命令。要查看这个命令的内置帮助信息,请在没有任何参数的情况下输入它,或使用 --help 指令输入它:

    $ trust
    usage: trust command <args>...
    
    Common trust commands are:
      list             List trust or certificates
      extract          Extract certificates and trust
      extract-compat   Extract trust compatibility bundles
      anchor           Add, remove, change trust anchors
      dump             Dump trust objects in internal format
    
    See 'trust <command> --help' for more information
  • 要列出所有系统信任定位符和证书,请使用信任列表命令

    $ trust list
    pkcs11:id=%d2%87%b4%e3%df%37%27%93%55%f6%56%ea%81%e5%36%cc%8c%1e%3f%bd;type=cert
        type: certificate
        label: ACCVRAIZ1
        trust: anchor
        category: authority
    
    pkcs11:id=%a6%b3%e1%2b%2b%49%b6%d7%73%a1%aa%94%f5%01%e7%73%65%4c%ac%50;type=cert
        type: certificate
        label: ACEDICOM Root
        trust: anchor
        category: authority
    ...
  • 要将信任定位符存储到系统范围的信任存储中,请使用 信任定位符 子命令并指定证书的路径。将 path.to/certificate.crt 替换为证书的路径及其文件名:

    # trust anchor path.to/certificate.crt
  • 要删除证书,请使用证书的路径或证书 ID:

    # trust anchor --remove path.to/certificate.crt
    # trust anchor --remove "pkcs11:id=%AA%BB%CC%DD%EE;type=cert"

其它资源

  • trust 命令的所有子命令都提供了详细的内置帮助,例如。

    $ trust list --help
    usage: trust list --filter=<what>
    
      --filter=<what>     filter of what to export
                            ca-anchors        certificate anchors
    ...
      --purpose=<usage>   limit to certificates usable for the purpose
                            server-auth       for authenticating servers
    ...

7.4. 其它资源

  • update-ca-trust(8)和 trust(1) man page

第 8 章 扫描系统以了解配置合规性和漏洞

合规审计是一个确定给定对象是否遵循合规性策略中指定的所有规则的过程。合规策略由安全专业人员定义,他们通常以检查清单的形式指定计算环境应使用的必要设置。

跨组织甚至同一组织内不同系统之间的合规政策可能有很大差异。这些政策之间的差异取决于每个系统的用途及其对组织的重要性。自定义软件设置和部署特征也使得需要自定义策略清单。

8.1. RHEL 中的配置合规工具

红帽企业 Linux 提供了一些工具,使您可以执行完全自动化的合规性审计。这些工具基于安全内容自动化协议(SCAP)标准,专为自动定制合规性策略而设计。

  • SCAP Workbench - scap-workbench 图形实用程序旨在在单个本地或远程系统上执行配置和漏洞扫描。您还可以使用它根据这些扫描和评估来生成安全报告。
  • OpenSCAP - OpenSCAP 库以及附带的oscap 命令行实用程序,旨在在本地系统上执行配置和漏洞扫描,验证配置合规性内容,并根据这些扫描和评估生成报告和指南。
  • SCAP 安全指南(SSG) - scap-security-guide 软件包为 Linux 系统提供了最新的安全策略集合。该指南包括一个实际强化建议目录,在适用的情况下与政府的要求相关联。该项目填补了一般政策要求和具体实施指南间的差距。
  • 脚本检查引擎(SCE) - SCE 是 SCAP 协议的扩展,可供管理员使用脚本语言(如 Bash、Python 和 Ruby)编写安全内容。SCE 扩展在 openscap-engine-sce 软件包中提供。SCE 本身不属于 SCAP 标准。

要在多个系统上远程执行自动合规审计,您可以将 OpenSCAP 解决方案用于红帽卫星。

8.2. 漏洞扫描

8.2.1. 红帽安全公告 OVAL 源

红帽企业 Linux 安全审计功能基于安全内容自动化协议(SCAP)标准。SCAP 是一种多用途规格框架,支持自动化配置、漏洞和补丁检查、技术控制合规性活动和安全衡量。

SCAP 规范创建一个生态系统,其中安全内容的格式是众所周知的且标准化的,尽管扫描程序或策略编辑器并不强制实施。这使得组织能够构建一次安全策略(SCAP 内容),无论他们采用的是多少家安全供应商。

开放式漏洞评估语言(OVAL)是 SCAP 的基本和最旧组件。与其他工具和自定义脚本不同,OVAL 以声明性方式描述资源的必需状态。OVAL 代码绝不直接执行,而是使用称为扫描器的 OVAL 解释器工具。OVAL 的声明性质可确保评估的系统状态不会被意外修改。

与所有其他 SCAP 组件一样,OVAL 也基于 XML。SCAP 标准定义多种文档格式。它们各自包括一种不同的信息,用于不同的目的。

红帽产品安全团队通过跟踪和调查影响红帽客户的所有安全问题,帮助客户评估和管理风险。它在红帽客户门户上提供及时简洁的补丁和安全公告。红帽创建和支持 OVAL 补丁定义,提供机器可读的安全公告版本。

由于平台、版本及其他因素之间存在差异,红帽产品安全严重性等级评级无法直接与第三方提供的通用漏洞评分系统(CVSS)基准评级一致。因此,我们建议您使用 RHSA OVAL 定义,而不是第三方提供的定义。

RHSA OVAL 定义可以单独提供完整的软件包,并在红帽客户门户上提供新安全公告的一小时内进行更新。

每个 OVAL 补丁定义将一对一映射到红帽安全顾问(RHSA)。由于 RHSA 可以包含多个漏洞的修复,每个漏洞都通过其通用漏洞和风险(CVE)名称单独列出,并在我们的公共错误数据库中有一个链接。

RHSA OVAL 定义旨在检查系统中安装的 RPM 软件包是否存在安全漏洞的版本。可以扩展这些定义以包括进一步检查,例如,查找软件包是否在易受攻击的配置中使用。这些定义旨在涵盖红帽提供的软件和更新。需要其他定义来检测第三方软件的补丁状态。

8.2.2. 扫描系统是否有漏洞

oscap命令行实用程序使您能够扫描本地系统,验证配置合规性内容,并根据这些扫描和评估生成报告和指南。此实用程序充当 OpenSCAP 库的前端,并根据它所处理的 SCAP 内容类型将其功能分组到模块(子命令)。

先决条件

  • AppStream存储库已启用。

流程

  1. 安装 openscap-scannerbzip2 软件包:

    # yum install openscap-scanner bzip2
  2. 下载系统的最新 RHSA OVAL 定义:

    # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL8/rhel-8.oval.xml.bz2 | bzip2 --decompress > rhel-8.oval.xml
  3. 扫描系统是否有漏洞并将结果保存到 vulnerability.html 文件中:

    # oscap oval eval --report vulnerability.html rhel-8.oval.xml

验证

  1. 在您选择的浏览器中检查结果,例如:

    $ firefox vulnerability.html &

其它资源

8.2.3. 扫描远程系统中的漏洞

您还可以通过 SSH 协议使用 the oscap-ssh 工具通过 OpenSCAP 扫描程序检查远程系统是否有漏洞。

先决条件

  • AppStream存储库已启用。
  • openscap-scanner 软件包安装在远程系统上。
  • SSH 服务器在远程系统上运行。

流程

  1. 安装 openscap-utilsbzip2 软件包:

    # yum install openscap-utils bzip2
  2. 下载系统的最新 RHSA OVAL 定义:

    # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL8/rhel-8.oval.xml.bz2 | bzip2 --decompress > rhel-8.oval.xml
  3. 使用 machine1 主机名扫描远程系统,SSH 在端口 22 上运行,joesec 用户名查找漏洞并将结果保存到 remote-vulnerability.html 文件中:

    # oscap-ssh joesec@machine1 22 Oval eval --report remote-vulnerability.html rhel-8.oval.xml

其它资源

8.3. 配置合规性扫描

8.3.1. RHEL 8 中的配置合规性

您可以使用配置合规扫描来符合特定组织定义的基准。例如,如果您与美国政府合作,您可能需要遵守操作系统保护配置文件(OSPP),如果您是一个支付处理器,您可能必须遵循支付卡行业数据安全标准(PCI-DSS)。您还可以执行配置合规性扫描来强化您的系统安全性。

红帽建议您遵循 SCAP 安全指南软件包中提供的安全内容自动化协议(SCAP)内容,因为它符合受影响组件的红帽最佳实践。

SCAP 安全指南软件包提供符合 SCAP 1.2 和 SCAP 1.3 标准的内容。openscap 扫描器实用程序与SCAP安全指南包中提供的SCAP 1.2和SCAP 1.3内容兼容。

重要

执行配置合规扫描不能保证系统合规。

SCAP 安全指南套件以数据流文档的形式为多个平台提供配置集。数据流是包含定义、基准、配置集和个别规则的文件。每条规则都规定合规的适用性和要求。RHEL 8 提供多个配置集来满足安全策略要求。除了行业标准之外,红帽数据流还包含用于修复失败规则的信息。

合规性扫描资源的结构

Data stream
   ├── xccdf
   |      ├── benchmark
   |            ├── profile
   |            |    ├──rule reference
   |            |    └──variable
   |            ├── rule
   |                 ├── human readable data
   |                 ├── oval reference
   ├── oval          ├── ocil reference
   ├── ocil          ├── cpe reference
   └── cpe           └── remediation

配置集是基于安全策略的一组规则,如 OSPP、PCI-DSS 和健康保障便携性和责任法案(HIPAA)。这可让您以自动化的方式审核系统,以符合安全标准。

您可以修改(尾部)配置集来自定义某些规则,例如密码长度。如需有关定制配置集的更多信息,请参阅使用 SCAP Workbench 自定义安全配置集

8.3.2. OpenSCAP 扫描的可能结果

根据您的系统的不同属性以及应用于 OpenSCAP 扫描的数据流和配置集,每个规则可能会生成特定的结果。这是可能的结果列表,并简要解释了它们的含义。

表 8.1. OpenSCAP 扫描的可能结果

结果解释

PASS

扫描没有发现与该规则有任何冲突。

失败

扫描发现与此规则冲突。

未检查

OpenSCAP 不对此规则执行自动评估。检查您的系统是否手动符合此规则。

不适用

此规则不适用于当前配置。

未选择

这个规则不是配置集的一部分。OpenSCAP 不评估此规则,也不会在结果中显示这些规则。

错误

扫描会出现错误。要获得更多信息,您可以使用 --verbose DEVEL 选项输入 oscap 命令。考虑打开错误报告

Unknown

扫描遇到了意外情况。要获得更多信息,您可以使用 '--verbose DEVEL 选项输入 oscap 命令。考虑打开错误报告

8.3.3. 查看配置集是否符合配置

在决定使用配置集进行扫描或修复前,您可以使用 theoscap info 子命令列出配置文件并检查其详细描述。

先决条件

  • 安装了 openscap-scannerscap-security-guide 软件包。

流程

  1. 使用 SCAP 安全指南项目提供的安全合规配置集列出所有可用的文件:

    $ ls /usr/share/xml/scap/ssg/content/
    ssg-firefox-cpe-dictionary.xml  ssg-rhel6-ocil.xml
    ssg-firefox-cpe-oval.xml        ssg-rhel6-oval.xml
    ...
    ssg-rhel6-ds-1.2.xml          ssg-rhel8-oval.xml
    ssg-rhel8-ds.xml              ssg-rhel8-xccdf.xml
    ...
  2. 使用 theoscap info 子命令显示关于所选数据流的详细信息。包含数据流的 XML 文件的名称中通过 -ds 字符串来指示。在 Profiles 部分,您可以找到可用配置集及其 ID 列表:

    $ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
    ...
    Profiles:
      Title: Health Insurance Portability and Accountability Act (HIPAA)
        Id: xccdf_org.ssgproject.content_profile_hipaa
      Title: PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 8
        Id: xccdf_org.ssgproject.content_profile_pci-dss
      Title: OSPP - Protection Profile for General Purpose Operating Systems
        Id: xccdf_org.ssgproject.content_profile_ospp
    ...
  3. 从 data-stream 文件中选择一个配置集,并显示所选配置集的附加详情。为此,可使用 oscap info 和 --profile 选项,后跟上一命令输出中显示的 ID 的最后一个部分。例如,HIPPA 配置集的 ID 是: xccdf_org.ssgproject.content_profile_hipaa,-- profile 选项的值为 hipaa

    $ oscap info --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
    ...
    Profile
    	Title: Health Insurance Portability and Accountability Act (HIPAA)
    
    	Description: The HIPAA Security Rule establishes U.S. national standards to protect individuals’ electronic personal health information that is created, received, used, or maintained by a covered entity.
    ...

其它资源

  • scap-security-guide(8) man page

8.3.4. 评估配置是否符合特定基准

要确定您的系统是否符合特定基准,请按照以下步骤操作:

先决条件

流程

  1. 评估系统与所选配置集的合规性,并将扫描结果保存到 report.html HTML 文件中,例如:

    $ sudo oscap xccdf eval --report report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
  2. 可选:扫描具有 machine1 主机名的远程系统,SSH 在端口 22 上运行,joesec 用户名 用于合规性,并将结果保存到 remote-report.html 文件中:

    $ oscap-ssh joesec@machine1 22 xccdf eval --report remote_report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

其它资源

8.4. 修复系统,使其与特定基准保持一致

使用这个步骤修复 RHEL 8 系统,使其与特定基准一致。这个示例使用了 Health Insurance Portability and Accountability Act(HIPAA)配置文件。

警告

如果不小心使用,则启用 Remediate 选项运行系统评估可能会导致系统无法正常工作。红帽不提供任何自动的方法来恢复由安全补救机制所做的更改。默认配置的 RHEL 系统支持自动安全补救功能。如果在安装后更改了您的系统,运行补救可能无法使其与所需安全配置兼容。

先决条件

  • scap-security-guide 软件包安装在 RHEL 8 系统中。

流程

  1. 使用带有 --remediate 选项的 oscap 命令:

    $ sudo oscap xccdf eval --profile hipaa --remediate /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
  2. 重启您的系统。

验证

  1. 使用 HIPAA 配置集评估系统的合规性,并将扫描结果保存在 hipaa_report.html 文件中:

    $ oscap xccdf eval --report hipaa_report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

其它资源

  • scap-security-guide(8)和 oscap(8)man page

8.5. 使用 SSG Ansible playbook 修复系统,使其与特定基准一致

使用 SCAP 安全指南项目中的 Ansible playbook 文件,通过特定的基准修复您的系统。这个示例使用了 Health Insurance Portability and Accountability Act(HIPAA)配置文件。

警告

如果不小心使用,则启用 Remediate 选项运行系统评估可能会导致系统无法正常工作。红帽不提供任何自动的方法来恢复由安全补救机制所做的更改。默认配置的 RHEL 系统支持自动安全补救功能。如果在安装后更改了您的系统,运行补救可能无法使其与所需安全配置兼容。

先决条件

  • scap-security-guide 软件包安装在 RHEL 8 系统中。
  • 已安装 ansible 软件包。如需更多信息,请参阅 Ansible 安装指南

流程

  1. 使用 Ansible 修复您的系统,使其与 HIPAA 一致:

    # ansible-playbook -i localhost, -c local /usr/share/scap-security-guide/ansible/rhel8-playbook-hipaa.yml
  2. 重新启动系统。

验证

  1. 使用 HIPAA 配置集评估系统的合规性,并将扫描结果保存在 hipaa_report.html 文件中:

    # oscap xccdf eval --profile hipaa --report hipaa_report.html /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

其它资源

8.6. 创建修复 Ansible playbook,使系统与特定基准保持一致

您可以创建一个 Ansible playbook,仅包含使您的系统与特定基准保持一致所需的补救。这个示例使用了 Health Insurance Portability and Accountability Act(HIPAA)配置文件。通过这个过程,您可以创建一个不满足已满足要求的较小的 playbook。按照以下步骤,您不会以任何方式修改您的系统,您只需为后续应用程序准备文件。

先决条件

  • scap-security-guide 软件包安装在 RHEL 8 系统中。

流程

  1. 扫描系统并保存结果:

    # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
  2. 根据上一步中生成的文件生成 Ansible playbook:

    # oscap xccdf generate fix --fix-type ansible --output hipaa-remediations.yml hipaa-results.xml
  3. hipaa-remediations.yml 文件包含步骤 1 中执行扫描期间失败的规则的 Ansible 修复。检查生成的文件后,您可以使用 ansible-playbook hipaa-remediations.yml 命令应用该文件。

验证

  1. 在您选择的文本编辑器中,检查 hipaa-remediations.yml 文件是否包含在第 1 步执行的扫描中失败的规则。

其它资源

8.7. 为后续应用程序创建补救 Bash 脚本

使用此流程创建一个 Bash 脚本,其中包含使您的系统与 HIPAA 等安全配置集一致的补救。通过以下步骤,您不会对系统进行任何修改,您只需为后续应用准备文件。

先决条件

  • scap-security-guide 软件包安装在 RHEL 8 系统中。

流程

  1. 使用 oscap 命令扫描系统,并将结果保存到 XML 文件中。在以下示例中,oscap 会根据 hipaa 配置集评估系统:

    # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
  2. 根据上一步中生成的结果文件生成 Bash 脚本:

    # oscap xccdf generate fix --profile hipaa --fix-type bash --output hipaa-remediations.sh hipaa-results.xml
  3. hipaa-remediations.sh 文件包含对在第 1 步中执行扫描过程中失败的规则进行修复。查看生成的文件后,当您位于与该文件相同的目录中时,您可以使用 ./hipaa-remediations.sh 命令应用该文件。

验证

  1. 在您选择的文本编辑器中,检查 hipaa-remediations.sh 文件包含在第 1 步执行的扫描中失败的规则。

其它资源

  • scap-security-guide(8)oscap(8)和 bash(1) man page

8.8. 使用 SCAP Workbench 使用自定义配置集扫描系统

scap-workbench软件包中包含的SCAP Workbench是一个图形化的实用程序,用户可以在单个本地或远程系统上进行配置和漏洞扫描,对系统进行修复,并根据扫描评估结果生成报告。请注意,与 oscap 命令行实用程序相比,SCAP Workbench 的功能有限。SCAP Workbench 以 data-stream 文件的形式处理安全内容。

8.8.1. 使用 SCAP Workbench 扫描和修复系统

要根据所选安全策略评估您的系统,请使用以下步骤。

先决条件

  • scap-workbench 软件包已经安装在您的系统中。

流程

  1. 要从 GNOME Classic 桌面环境运行 SCAP Workbench,请按 Super 键进入 "活动概览",键入 scap-workbench,然后按 Enter 键。或者,使用:

    $ scap-workbench &
  2. 使用以下选项之一选择安全策略:

    • 在起始窗口中加载内容按钮
    • 从 SCAP 安全指南打开内容
    • File 中打开 Other Content,搜索相关的 XCCDF、SCAP RPM 或数据流文件。

      SCAP 工作台启动
  3. 您可以选择Remediate 复选框来允许自动修正系统配置。启用此选项后,SCAP Workbench 会尝试根据策略应用的安全规则更改系统配置。这个过程应该修复系统扫描过程中失败的相关检查。

    警告

    如果不小心使用,则启用 Remediate 选项运行系统评估可能会导致系统无法正常工作。红帽不提供任何自动的方法来恢复由安全补救机制所做的更改。默认配置的 RHEL 系统支持自动安全补救功能。如果在安装后更改了您的系统,运行补救可能无法使其与所需安全配置兼容。

  4. 单击扫描按钮,使用所选配置集扫描您的系统

    SCAP 工作台结果
  5. 要以 XCCDF、ARF 或 HTML 文件的形式保存扫描结果,请点击 Save Results combo 框。选择 HTML Report 选项,以人类可读格式生成扫描报告。XCCDF 和 ARF(数据流)格式适合进一步自动处理。您可以重复选择所有三个选项。
  6. 要将基于结果的补救导出到文件,请使用 Generate remediation role 弹出菜单。

8.8.2. 使用 SCAP Workbench 自定义安全配置集

您可以通过更改特定规则中的参数(如最小密码长度)、删除您涵盖的规则不同方式,并选择附加规则来自定义安全配置集,以实施内部策略。您无法通过自定义配置集来定义新规则。

以下步骤演示了如何使用SCAP Workbench自定义 (定制)配置集。您还可以保存用于 oscap 命令行实用程序的定制配置集。

先决条件

  • scap-workbench 软件包已经安装在您的系统中。

流程

  1. Run SCAP Workbench,选择要自定义的配置集,方法是使用 SCAP 安全指南 中的 Open 内容,或者在 File 菜单中打开其他 内容。
  2. 要根据您的需要调整所选的安全配置集,请单击 Customize 按钮。

    这会打开新的 Customization 窗口,允许您在不更改原始数据流文件的情况下修改当前选择的配置集。选择新的配置文件 ID。

    选择新配置集的 ID
  3. 使用树结构以及规则组织到逻辑组或搜索字段查找要修改的规则
  4. 使用树结构中的复选框包含或排除规则,或者在适用情况下修改规则中的值。

    在 OSPP 配置集中自定义规则
  5. 单击 OK 按钮以确认更改。
  6. 要永久存储您的更改,请使用以下选项之一:

    • 使用 File 菜单中的 Save Customization Only 单独 保存自定义文件。
    • 通过在 File 菜单中 保存 All 来保存 一次所有安全内容。

      如果您选择了 Into a directory 选项,SCAP Workbench 将数据流文件和自定义文件保存到指定的位置。您可以使用它作为备份解决方案。

      通过选择 As RPM 选项,您可以指示SCAP Workbench 创建包含数据流文件和自定义文件的 RPM 软件包。这可用于将安全内容分发到无法远程扫描的系统,以及提供内容以便进一步处理。

注意

因为SCAP Workbench 不支持对定制配置集的基于结果的补救,所以请使用带有oscap命令行实用程序导出的补救

8.9. 安装后立即部署符合安全配置集的系统

您可以在安装过程后立即使用 OpenSCAP 套件部署符合安全配置集的 RHEL 系统,如 OSPP、PCI-DSS 和 HIPAA 配置集。使用此部署方法时,您可以使用修复脚本(例如密码强度和分区的规则)应用之后无法应用的特定规则。

8.9.1. 使用图形安装部署基本兼容 RHEL 系统

使用此流程部署与特定基准兼容的 RHEL 系统。这个示例为常规目的操作系统(OSPP)使用保护配置集。

先决条件

  • 您已引导到 图形化 安装程序。请注意: OSCAP Anaconda 插件不只支持文本安装。
  • 您已访问 安装概述 窗口。

流程

  1. 安装概述 窗口中点击 软件选择。此时会打开 软件选择窗口。
  2. Base Environment 窗格中选择 服务器 环境。您只能选择一个基本环境。

    警告

    如果要部署兼容的系统,请不要使用 Server with GUI 基础环境的服务器。作为 SCAP Security Guide 的一部分提供的安全配置集可能与 Server with GUI 的扩展软件包不兼容。如需更多信息,请参阅 BZ#1648162BZ#1787156BZ#1816199

  3. 点击 完成 应用设置并返回 安装概述 窗口。
  4. 点击 安全策略。此时会打开 Security Policy 窗口。
  5. 要在系统中启用安全策略,将Apply security policy 切换为 ON
  6. 从配置集栏中选择 Protection Profile for General Purpose Operating Systems.
  7. Select Profile 来确认选择。
  8. 确认在窗口底部显示 Changes that were done or need to be done。完成所有剩余的手动更改。
  9. 因为 OSPP 有必须满足的严格的分区要求,所以可以为 /boot/home/var/var/log/var/tmp/var/log/audit 创建单独的分区。
  10. 完成图形安装过程。

    注意

    图形安装程序在安装成功后自动创建对应的 Kickstart 文件。您可以使用 /root/anaconda-ks.cfg 文件自动安装兼容 OSPP 的系统。

验证

  1. 要在安装完成后检查系统当前的状态,请重启系统并启动新的扫描:

    # oscap xccdf eval --profile ospp --report eval_postinstall_report.html /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

其它资源

8.9.2. 使用 Kickstart 部署基本兼容 RHEL 系统

使用此流程部署符合特定基准的 RHEL 系统。这个示例为常规目的操作系统(OSPP)使用保护配置集。

先决条件

  • scap-security-guide 软件包安装在 RHEL 8 系统中。

流程

  1. 在您选择的编辑器中打开 /usr/share/scap-security-guide/kickstarts/ssg-rhel8-ospp-ks.cfg Kickstart 文件。
  2. 更新分区方案以符合您的配置要求。要满足 OSPP 合规性,需要保留 /boot, /home, /var, /var/log, /var/tmp/var/log/audit 的独立分区。 您只能更改分区大小。

    警告

    因为 OSCAP Anaconda Addon 插件不支持只使用文本安装,不要在 Kickstart 文件中使用 text 选项。.如需更多信息,请参阅 RHBZ#1674001

  3. 按照使用 Kickstart 执行自动安装中所述启动 Kickstart 安装
重要

使用哈希格式的密码无法检测 OSPP 要求。

验证

  1. 要在安装完成后检查系统当前的状态,请重启系统并启动新的扫描:

    # oscap xccdf eval --profile ospp --report eval_postinstall_report.html /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

其它资源

8.10. 扫描容器和容器镜像以查找漏洞

使用这个流程查找容器或容器镜像中的安全漏洞。

注意

oscap-podman 命令从 RHEL 8.2 开始提供。对于RHEL 8.1和8.0,请参阅 Using OpenSCAP for scanning containers in RHEL 8

先决条件

  • openscap-utils 包已经安装完毕。

流程

  1. 下载系统的最新 RHSA OVAL 定义:

    # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL8/rhel-8.oval.xml.bz2 | bzip2 --decompress > rhel-8.oval.xml
  2. 获取容器或容器镜像的 ID,例如:

    # podman images
    REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
    registry.access.redhat.com/ubi8/ubi   latest   096cae65a207   7 weeks ago   239 MB
  3. 扫描容器或容器镜像中的漏洞,并将结果保存到 vulnerability.html 文件中:

    # oscap-podman 096cae65a207 Oval eval --report vulnerability.html rhel-8.oval.xml

    请注意,oscap-podman 命令需要 root 特权,容器的 ID 是第一个参数。

验证

  1. 在您选择的浏览器中检查结果,例如:

    $ firefox vulnerability.html &

其它资源

  • 如需更多信息,请参阅 oscap-podman(8)和 oscap(8)man page。

8.11. 使用特定基准评估容器或容器镜像的安全性合规性

按照以下步骤,利用特定的安全基准评估容器或容器镜像的合规性,如操作系统保护配置文件(OSPP)、支付卡行业数据安全标准(PCI-DSS)和健康保险可移植性和责任法案(HIPAA)。

注意

oscap-podman 命令从 RHEL 8.2 开始提供。对于RHEL 8.1和8.0,请参阅 Using OpenSCAP for scanning containers in RHEL 8

先决条件

  • 已安装 openscap-utilsscap-security-guide 软件包。

流程

  1. 获取容器或容器镜像的 ID,例如:

    # podman images
    REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
    registry.access.redhat.com/ubi8/ubi   latest   096cae65a207   7 weeks ago   239 MB
  2. 使用 HIPAA 配置集评估容器镜像的合规性,并将扫描结果保存到 report.html HTML 文件中

    # oscap-podman 096cae65a207 xccdf eval --report report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

    如果要评估与 OSPP 或 PCI-DSS 基准的安全合规性,Replace096cae65a207 带有容器镜像 ID 和 hipaawithospp orpci-dss。请注意,oscap-podman 命令需要 root 权限。

验证

  1. 在您选择的浏览器中检查结果,例如:

    $ firefox report.html &
注意

标记为不可应用的规则是不适用于容器化系统的规则。这些规则仅适用于裸机和虚拟化系统。

其它资源

8.12. RHEL 中支持 SCAP 安全指南的版本

官方支持的 SCAP 安全指南版本在相关的 RHEL 次要版本或 RHEL 的相关批处理更新中提供。

表 8.2. RHEL 中支持 SCAP 安全指南的版本

Red Hat Enterprise Linux 版本SCAP 安全指南版本

RHEL 6.6

scap-security-guide-0.1.18-3.el6

RHEL 6.9

scap-security-guide-0.1.28-3.el6

RHEL 6.10

scap-security-guide-0.1.28-4.el6

RHEL 7.2 AUS

scap-security-guide-0.1.25-3.el7

RHEL 7.3 AUS

scap-security-guide-0.1.30-5.el7_3

RHEL 7.4 AUS, E4S

scap-security-guide-0.1.33-6.el7_4

RHEL 7.5(批处理更新)

scap-security-guide-0.1.36-10.el7_5

RHEL 7.6 EUS

scap-security-guide-0.1.40-13.el7_6

RHEL 7.7 EUS

scap-security-guide-0.1.43-13.el7

RHEL 7.8(批处理更新)

scap-security-guide-0.1.46-11.el7

RHEL 7.9(批处理更新)

scap-security-guide-0.1.54-7.el7_9

RHEL 8.0 SAP

scap-security-guide-0.1.42-11.el8

RHEL 8.1 EUS

scap-security-guide-0.1.47-8.el8_1

RHEL 8.2(批量更新)

scap-security-guide-0.1.48-10.el8_2

RHEL 8.3

scap-security-guide-0.1.50-16.el8_3

RHEL 8.4

scap-security-guide-0.1.54-5.el8

8.13. RHEL 8 中支持的 SCAP 安全指南配置集

仅使用 RHEL 的特定次要版本中提供的 SCAP 内容。这是因为,参与强化的组件有时会使用新功能进行更新。SCAP 内容会改变来反映这些更新,但并不总是向后兼容。

在下表中,您可以找到每个 RHEL 次要版本中提供的配置集,以及配置集与其匹配的策略版本。

表 8.3. RHEL 8.4 中支持的 SCAP 安全指南配置集

配置集名称配置集 ID策略版本

法国信息系统安全局(ANSSI)BP-028 增强级

xccdf_org.ssgproject.content_profile_anssi_bp28_enhanced

1.2

法国信息系统安全局(ANSSI)BP-028 Intermediary Level

xccdf_org.ssgproject.content_profile_anssi_bp28_intermediary

1.2

法国信息系统安全局(ANSSI)BP-028 最低级别

xccdf_org.ssgproject.content_profile_anssi_bp28_minimal

1.2

CIS Red Hat Enterprise Linux 8 Benchmark

xccdf_org.ssgproject.content_profile_cis

1.0.0

非联邦信息系统和组织中未分类的信息(NIST 800-171)

xccdf_org.ssgproject.content_profile_cui

r1

澳大利亚网络安全中心(ACSC)Essential Eight

xccdf_org.ssgproject.content_profile_e8

未版本化

健康保障便携性和责任法案(HIPAA)

xccdf_org.ssgproject.content_profile_hipaa

未版本化

常规目的操作系统保护配置集

xccdf_org.ssgproject.content_profile_ospp

4.2.1

Red Hat Enterprise Linux 8 的 PCI-DSS v3.2.1 Control Baseline

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

红帽企业 Linux 8 的国防部安全技术实施指南(DISA STIG)

xccdf_org.ssgproject.content_profile_stig

V1R1

表 8.4. RHEL 8.3 支持 SCAP 安全指南配置集

配置集名称配置集 ID策略版本

CIS Red Hat Enterprise Linux 8 Benchmark

xccdf_org.ssgproject.content_profile_cis

1.0.0

非联邦信息系统和组织中未分类的信息(NIST 800-171)

xccdf_org.ssgproject.content_profile_cui

r1

澳大利亚网络安全中心(ACSC)Essential Eight

xccdf_org.ssgproject.content_profile_e8

未版本化

健康保障便携性和责任法案(HIPAA)

xccdf_org.ssgproject.content_profile_hipaa

未版本化

常规目的操作系统保护配置集

xccdf_org.ssgproject.content_profile_ospp

4.2.1

Red Hat Enterprise Linux 8 的 PCI-DSS v3.2.1 Control Baseline

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

[DRAFT] 针对红帽企业 Linux 8 国防部安全技术实施指南(DISA STIG)

xccdf_org.ssgproject.content_profile_stig

草案

表 8.5. RHEL 8.2 中支持的 SCAP 安全指南配置集

配置集名称配置集 ID策略版本

澳大利亚网络安全中心(ACSC)Essential Eight

xccdf_org.ssgproject.content_profile_e8

未版本化

常规目的操作系统保护配置集

xccdf_org.ssgproject.content_profile_ospp

4.2.1

Red Hat Enterprise Linux 8 的 PCI-DSS v3.2.1 Control Baseline

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

Red Hat Enterprise Linux 8 [DRAFT] DISA STIG

xccdf_org.ssgproject.content_profile_stig

草案

表 8.6. RHEL 8.1 支持 SCAP 安全指南配置集

配置集名称配置集 ID策略版本

常规目的操作系统保护配置集

xccdf_org.ssgproject.content_profile_ospp

4.2.1

Red Hat Enterprise Linux 8 的 PCI-DSS v3.2.1 Control Baseline

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

表 8.7. RHEL 8.0 中支持的 SCAP 安全指南配置集

配置集名称配置集 ID策略版本

OSPP - 常规目的操作系统的保护配置集

xccdf_org.ssgproject.content_profile_ospp

草案

Red Hat Enterprise Linux 8 的 PCI-DSS v3.2.1 Control Baseline

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

其它资源

第 9 章 使用 AIDE 检查完整性

高级入侵检测环境(Advanced Intrusion Detection Environment,简称 AIDE)是一个实用工具,它可以创建系统上的文件数据库,然后利用该数据库来确保文件的完整性,并检测系统入侵。

9.1. 安装 AIDE

安装 AIDE 并启动其数据库需要执行下列步骤。

先决条件

  • AppStream存储库已启用。

流程

  1. 安装 aide 软件包:

    # yum install aide
  2. 生成初始数据库:

    # aide --init
    注意

    在默认配置中,aide --init 命令仅检查 /etc/aide.conf 文件中定义的一组目录和文件。要在 AIDE 数据库中包含其他目录或文件,并更改其监视的参数,请相应地编辑 /etc/aide.conf

  3. 要使用数据库,请从初始数据库文件名中删除 .new 子字符串:

    # mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
  4. 要更改 AIDE 数据库的位置,请编辑 /etc/aide.conf 文件并修改 DBDIR 值。要获得额外的安全性,请将数据库、配置和 /usr/sbin/aide 二进制文件存储在安全位置,如只读介质。

9.2. 使用 AIDE执行完整性检查

先决条件

流程

  1. 启动手动检查:

    # aide --check
    Start timestamp: 2018-07-11 12:41:20 +0200 (AIDE 0.16)
    AIDE found differences between database and filesystem!!
    ...
    [trimmed for clarity]
  2. 至少,将系统配置为每周运行 AIDE。最好地,每天运行 AIDE。例如,要使用 cron 命令计划每天在 04:05 a. m. 执行 AIDE,请在 /etc/crontab 文件中添加以下行:

     05 4 * * * root /usr/sbin/aide --check

9.3. 更新 AIDE 数据库

在验证您的系统更改后,如软件包更新或配置文件调整,红帽建议更新您的基准 AIDE 数据库。

先决条件

流程

  1. 更新您的基准 AIDE 数据库:

    # aide --update

    aide --update 命令创建 /var/lib/aide/aide.db.new.gz 数据库文件。

  2. 若要开始使用更新的数据库进行完整性检查,请从文件名中删除 .new 子字符串。

第 10 章 使用 LUKS 加密块设备

磁盘加密通过加密来保护块设备中的数据。要访问设备的解密内容,用户必须提供密语或密钥作为身份验证。这对于移动计算机和可移动介质而言尤为重要:即使它已从系统物理上移除,它也有助于保护设备的内容。LUKS 格式是 RHEL 中块设备加密的默认实现。

10.1. LUKS 磁盘加密

Linux Unified Key Setup-disk-format(LUKS)允许您加密块设备,并提供一组简化加密设备管理的工具。LUKS 允许多个用户密钥解密主密钥,用于批量加密分区。

RHEL 使用 LUKS 执行块设备加密。默认情况下,在安装过程中取消选中加密块设备的选项。如果您选择加密磁盘的选项,则系统会在每次引导计算机时提示您输入密码短语。这个密码短语将解锁用于加密您的分区所使用的加密密钥。如果您选择修改默认的分区表,可以选择加密哪个分区。这是在分区表设置中设定的。

LUKS 做什么

  • LUKS 对整个块设备进行加密,因此非常适合保护移动设备的内容,如可移动存储介质或笔记本电脑磁盘驱动器。
  • 加密块设备的底层内容是任意的,这有助于加密交换设备。对于将特殊格式化块设备用于数据存储的某些数据库,这也很有用。
  • LUKS 使用现有的设备映射器内核子系统。
  • LUKS 增强了密码短语,防止字典攻击。
  • LUKS 设备包含多个密钥插槽,允许用户添加备份密钥或密码短语。

LUKS 不能做什么

  • LUKS 等磁盘加密解决方案仅在您的系统关闭时保护数据。当系统处于 on 状态并且 LUKS 解密了磁盘后,该磁盘上的文件将可供通常具有访问权限的任何人使用。
  • LUKS 不适用于需要许多用户具有同一设备的不同访问密钥的情况。LUKS1 格式提供八个关键插槽,LUKU2 最多提供 32 个密钥插槽。
  • LUKS 不适用于需要文件级加密的应用程序。

加密系统

LUKS 使用的默认密码是 aes-xts-plain64。LUKS 的默认密钥大小为 512 字节。Anaconda (XTS 模式)的 LUKS 的默认密钥大小为 512 位。可用的加密系统包括:

  • AES - 高级加密标准
  • Twofish(128 位块加密)
  • Serpent

10.2. RHEL 8 中的 LUKS 版本

在 RHEL 8 中,LUKS 加密的默认格式是 LUKS2。旧版 LUKS1 格式仍然被完全支持,它以与早期 RHEL 版本兼容的格式提供。

LUKS2 格式旨在启用各种部分的未来更新,而无需修改二进制结构。LUKS2 在内部使用 JSON 文本格式进行元数据,提供元数据冗余,检测元数据损坏,允许从元数据副本进行自动修复。

重要

不要在必须与只支持 LUKS1 的传统系统兼容的系统中使用 LUKS2。请注意,RHEL 7 支持版本 7.6 起的 LUKS2 格式。

警告

LUKS2 和 LUKS1 使用不同的命令加密该磁盘。对 LUKS 版本使用错误的命令可能会导致数据丢失。

LUKS 版本加密命令

LUKS2

cryptsetup reencrypt

LUKS1

cryptsetup-reencrypt

在线重新加密

LUKS2 格式支持在设备正在使用时重新加密加密设备。例如:您不必卸载该设备中的文件系统来执行以下任务:

  • 更改卷密钥
  • 更改加密算法

加密非加密设备时,您仍然必须卸载该文件系统。您可以在简短初始化加密后重新挂载文件系统。

LUKS1 格式不支持在线重新加密。

转换

LUKS2 格式由 LUKS1 实现。在某些情况下,您可以将 LUKS1 转换为 LUKS2。在以下情况下无法进行转换:

  • LUKS1 设备被标记为由基于策略的解密(PBD - Clevis)解决方案使用。当检测到 some luksmeta 元数据时,cryptsetup 工具会拒绝转换设备。
  • 设备正在活跃。该设备必须处于不活跃状态,才能进行转换。

10.3. LUKS2 重新加密过程中数据保护选项

LUKS2 提供了几个选项,在重新加密过程中优先选择性能或数据保护:

checksum

这是默认的模式。它在数据保护和性能之间取得平衡。

这个模式将单独的扇区校验和保存在重新加密区域,因此恢复过程可以检测哪些 LUKS2 扇区已经重新加密。模式要求块设备扇区写入具有“原子”性。

journal
这是最安全的模式,也是速度最慢的模式。此模式记录二进制区域中的再加密区域,因此 LUKS2 将数据写入两次。
none
此模式优先选择性能,不提供数据保护。它仅保护数据,以防止安全进程终止,如 SIGTERM 信号 或按 Ctrl+C 的用户。任何意外的系统崩溃或应用程序崩溃都可能会导致数据崩溃。

您可以使用 cryptsetup--resilience 选项选择模式。

如果 LUKS2 重新加密进程意外终止了强制终止,LUKU2 可使用以下方法之一执行恢复:

  • 自动执行下一个 LUKS2 设备打开操作。此操作可以由 cryptsetup open 命令触发,或者通过 systemd-cryptsetup 连接设备。
  • 在 LUKS2 设备 上使用 cryptsetup 修复 命令手动手动。

10.4. 使用 LUKS2 加密块设备上的现有数据

这个过程使用 LUKS2 格式加密设备中的数据。新的 LUKS 标头保存在设备的标头中。

先决条件

  • 块设备包含一个文件系统。
  • 已备份了数据。

    警告

    在加密过程中可能会丢失您的数据:由于硬件、内核或人为故障。在开始加密数据之前,请确保您有可靠的备份。

流程

  1. 卸载您要加密的设备中的所有文件系统。例如:

    # umount /dev/sdb1
  2. 为存储 LUKS 标头腾出空间。选择适合您的场景的以下选项之一:

    • 如果是加密逻辑卷,您可以扩展逻辑卷而不重新定义文件系统大小。例如:

      # lvextend -L+32M vg00/lv00
    • 使用分区管理工具(如 parted )扩展分区。
    • 缩小该设备的文件系统。您可以将 resize2fs 实用程序用于 ext2、ext3 或 ext4 文件系统。请注意,您无法缩小 XFS 文件系统。
  3. 初始化加密。例如:

    # cryptsetup reencrypt \ --encrypt \ --init-only \ --reduce-device-size 32M \ /dev/sdb1 sdb1_encrypted

    该命令会要求您输入密码短语并启动加密过程。

  4. 挂载该设备:

    # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted
  5. 启动在线加密:

    # cryptsetup reencrypt --resume-only /dev/sdb1

其它资源

  • cryptsetup(8)lvextend(8)resize2fs(8)和 parted(8)man page

10.5. 使用带有分离标头的 LUKS2 加密块设备上的现有数据

此流程加密块设备中的现有数据,而不为存储 LUKS 标头创建可用空间。标头存储在分离的位置,它也充当额外的安全层。该流程使用 LUKS2 加密格式。

先决条件

  • 块设备包含一个文件系统。
  • 已备份了数据。

    警告

    在加密过程中可能会丢失您的数据:由于硬件、内核或人为故障。在开始加密数据之前,请确保您有可靠的备份。

流程

  1. 卸载该设备中的所有文件系统。例如:

    # umount /dev/sdb1
  2. 初始化加密:

    # cryptsetup reencrypt \ --encrypt \ --init-only \ --header /path/to/header \ /dev/sdb1 sdb1_encrypted

    /path/to/header 替换为使用分离的 LUKS 标头指向该文件的路径。必须可以访问分离的 LUKS 标头,以便稍后可以解锁加密的设备。

    该命令会要求您输入密码短语并启动加密过程。

  3. 挂载该设备:

    # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted
  4. 启动在线加密:

    # cryptsetup reencrypt --resume-only --header /path/to/header /dev/sdb1

其它资源

  • cryptsetup(8) man page

10.6. 使用 LUKS2 加密空白块设备

此流程提供有关使用 LUKS2 格式加密空白块设备的信息。

先决条件

  • 空白块设备。

流程

  1. 将分区设置为加密的 LUKS 分区:

    # cryptsetup luksFormat /dev/sdb1
  2. 打开加密的 LUKS 分区:

    # cryptsetup open /dev/sdb1 sdb1_encrypted

    这样可解锁分区并使用设备映射器将其映射到新设备中。此警报会警告内核 设备 是加密设备,应通过 LUKS 并使用 /dev/mapper/device_mapped_name 来解决,以免覆盖加密的数据。

  3. 要向分区写入加密的数据,必须通过设备映射名称进行访问。为此,您必须创建一个文件系统。例如:

    # mkfs -t ext4 /dev/mapper/sdb1_encrypted
  4. 挂载该设备:

    # mount /dev/mapper/sdb1_encrypted mount-point

其它资源

  • cryptsetup(8) man page

10.7. 使用存储角色创建 LUKS 加密卷

您可以通过运行 Ansible playbook,使用 storage 角色来创建和配置使用 LUKS 加密的卷。

先决条件

  • 您已在要运行 playbook 的系统中安装了 Red Hat Ansible Engine。

    注意

    您不必在要创建卷的系统中安装 Red Hat Ansible Automation Platform。

  • Ansible 控制器上安装了 rhel-system-roles 软件包。
  • 您有一个清单文件详细描述了您要使用存储系统角色部署 LUKS 加密卷的系统。

流程

  1. 使用以下内容创建新 playbook.yml 文件:

    - hosts: all
      vars:
        storage_volumes:
          - name: barefs
            type: disk
            disks:
             - sdb
            fs_type: xfs
            fs_label: label-name
            mount_point: /mnt/data
            encryption: true
            encryption_password: your-password
      roles:
       - rhel-system-roles.storage
  2. 可选:验证 playbook 语法:

    # ansible-playbook --syntax-check playbook.yml
  3. 在清单文件上运行 playbook:

    # ansible-playbook -i inventory.file /path/to/file/playbook.yml

其它资源

第 11 章 使用基于策略的解密配置加密卷的自动解锁

基于策略的解密(PBD)是一系列技术,可在物理和虚拟机上实现加密的根和辅助硬盘卷的解锁。PBD 使用各种解锁方法,如用户密码、受信任的平台模块(TPM)设备、连接到系统的 PKCS #11 设备,如智能卡或特殊的网络服务器。

PBD 允许将不同的解锁方法合并到策略中,从而以不同的方式解锁同一卷。当前在红帽企业 Linux 中实施 PBD 包括 Clevis 框架和名为 pin 的插件。每个 pin 都提供单独的解锁功能。目前,以下 pins 可用:

  • Tang - 允许使用网络服务器解锁卷
  • tpm2 - 允许使用 TPM2 策略解锁卷

Network Bound Disc Enc Encryption(NBDE)是 PBD 的子类别,允许将加密的卷绑定到特殊的网络服务器。NBDE 的当前实施包括 Tang 服务器和 Tang 服务器本身的 Clevis pin。

11.1. 网络绑定磁盘加密

在 Red Hat Enterprise Linux 中,NBDE 通过以下组件和技术实施:

图 11.1. 使用 LUKS1- 加密卷时的 NBDE 方案。luksmeta 软件包不用于 LUKS2 卷。

RHEL 安全指南 453350 0717BDE NBDE

Tang 是一个将数据绑定到网络存在的服务器。当系统绑定到特定安全网络时,它会使包含可用数据的系统变得可用。Tang 是无状态的,不需要 TLS 或身份验证。与基于 escrow 的解决方案不同,服务器存储所有加密密钥并了解以前使用的每个密钥,Tang 从未与任何客户端密钥交互,因此永远不会从客户端获得任何识别信息。

Clevis 是自动化解密的可插拔框架。在 NBDE 中,Clevis 提供 LUKS 卷的自动解锁。clevis 软件包提供了功能的客户端。

Clevis pin 是 Clevis 框架的一个插件。其中一个 pins 是实现与 NBDE 服务器交互的插件 - Tang。

Clevis 和 Tang 是通用客户端和服务器组件,提供网络绑定加密。在 Red Hat Enterprise Linux 中,它们与 LUKS 一起使用,以加密和解密 root 和非 root 存储卷,从而完成 Network-Bound 磁盘加密。

客户端和服务器端组件都使用 José 库来执行加密和解密操作。

当您开始调配 NBDE 时,Tang 服务器的 Clevis pin 获取 Tang 服务器公告的对称密钥的列表。或者,由于密钥是非对称的,因此 Tang 的公钥列表可以分发到带外,以便客户端能够在不访问 Tang 服务器的情况下运行。此模式称为脱机调配

Tang 的 Clevis pin 使用其中一个公钥来生成唯一的加密密钥。使用此密钥加密数据后,密钥将被丢弃。Clevis 客户端应将此调配操作生成的状态存储在方便的位置。这种加密数据的过程就是调配步骤

LUKS 版本 2(LUKS2)是 Red Hat Enterprise Linux 8 的默认格式,因此 NBDE 的置备状态作为令牌存储在 LUKS2 标头中。通过 theluksmeta 软件包为 NBDE 调配状态仅用于使用 LUKS1 加密的卷。Tang 的 Clevis pin 支持 LUKS1 和 LUKS2,无需规格。

当客户端准备好访问其数据时,它会加载调配步骤中生成的元数据,并响应恢复加密密钥。此过程是恢复步骤

在 NBDE 中,Clevis 使用 pin 绑定 LUKS 卷,以便自动解锁它。成功完成绑定流程后,可以使用提供的 Dracut 解锁程序解锁磁盘。

注意

如果将 kdump 内核崩溃转储机制设置为将系统内存的内容保存到 LUKS 加密的设备中,则会提示您在第二个内核引导过程中输入密码。

11.2. 安装加密客户端 - Clevis

使用 Clevis 可插入框架在您的系统上部署和启动此流程。

流程

  1. 在带有加密卷的系统中安装 Clevis 及其 pins:

    # yum install clevis
  2. 要解密数据,请使用 clevis 解密 命令并以 JSON Web 加密(JWE)格式提供密码文本,例如:

    $ clevis decrypt < secret.jwe

其它资源

  • cllevis(1) man page
  • 在不带任何参数输入 clevis 命令后内置 CLI 帮助:

    $ clevis
    Usage: clevis COMMAND [OPTIONS]
    
    clevis decrypt             Decrypts using the policy defined at encryption time
    clevis encrypt sss         Encrypts using a Shamir's Secret Sharing policy
    clevis encrypt tang        Encrypts using a Tang binding server policy
    clevis encrypt tpm2        Encrypts using a TPM2.0 chip binding policy
    clevis luks bind           Binds a LUKS device using the specified policy
    clevis luks list           Lists pins bound to a LUKSv1 or LUKSv2 device
    clevis luks pass           Returns the LUKS passphrase used for binding a particular slot.
    clevis luks regen          Regenerate LUKS metadata
    clevis luks report         Report any key rotation on the server side
    clevis luks unbind         Unbinds a pin bound to a LUKS volume
    clevis luks unlock         Unlocks a LUKS volume

11.3. 使用 SELinux 处于 enforcing 模式的部署 Tang 服务器

使用这个流程将自定义端口上运行的 Tang 服务器部署为 SELinux enforcing 模式的受限服务。

先决条件

  • policycoreutils-python-utils 包及其依赖项已经安装。

流程

  1. 要安装 tang 软件包及其依赖项,以 root 用户身份输入以下命令:

    # yum install tang
  2. 选择一个未设置的端口,例如 7500/tcp,并允许 tangd 服务绑定到该端口:

    # semanage port -a -t tangd_port_t -p tcp 7500

    请注意,某个端口一次只能由一个服务使用,因此尝试使用已占用的端口意味着 ValueError: Port 已定义的 错误消息。

  3. 在防火墙中打开端口:

    # firewall-cmd --add-port=7500/tcp
    # firewall-cmd --runtime-to-permanent
  4. 启用 tangd 服务:

    # systemctl enable tangd.socket
  5. 创建覆盖文件:

    # systemctl edit tangd.socket
  6. 在以下编辑器屏幕中,打开了位于 /etc/systemd/system/tangd.socket.d/ 目录中的空 override.conf 文件,通过添加以下行将 Tang 服务器的默认端口从 80 改为之前选择的编号:

    [Socket]
    ListenStream=
    ListenStream=7500

    保存文件并退出编辑器。

  7. 重新载入更改的配置:

    # systemctl daemon-reload
  8. 检查您的配置是否正常工作:

    # systemctl show tangd.socket -p Listen
    Listen=[::]:7500 (Stream)
  9. 启动 tangd 服务:

    # systemctl start tangd.socket

    由于 tangd 使用 systemd 套接字激活机制,因此服务器将在第一次连接登录时立即启动。在第一次启动时会自动生成一组新的加密密钥。要执行手动生成密钥等加密操作,请使用 jose 工具。

其它资源

  • tang(8)semanage(8)firewall-cmd(1)、 jose(1)、 systemd.unit(5)systemd.socket(5) man page

11.4. 轮转 Tang 服务器密钥并更新客户端上的绑定

使用以下步骤轮转 Tang 服务器密钥,并在客户端上更新现有的绑定。您轮转它们的确切间隔取决于您的应用程序、密钥大小以及机构策略。

或者,您可以使用 nbde_server RHEL 系统角色轮转 Tang 密钥。如需更多信息,请参阅使用 nbde_server 系统角色来设置多个 Tang 服务器

先决条件

  • Tang 服务器正在运行。
  • clevisclevis-luks 软件包安装在您的客户端上。
  • 请注意,RHEL 8.2 中引进了clevis luks list、c levis luks 报告和 clevis luks regen

流程

  1. 重命名 /var/db/tang 键数据库目录中的所有键,使其具有一个前导 .,以将它们从公告中隐藏。请注意,以下示例中的文件名与 Tang 服务器密钥数据库目录中的唯一文件名不同:

    # cd /var/db/tang
    # ls -l
    -rw-r--r--. 1 root root 349 Feb  7 14:55 UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
    -rw-r--r--. 1 root root 354 Feb  7 14:55 y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
    # mv UV6dqXSwe1bRKG3KbJmdiR020hY.jwk .UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
    # mv y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk .y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
  2. 检查是否重命名了 Tang 服务器公告中的所有键:

    # ls -l
    total 0
  3. 使用 Tang 服务器上的 /var/db/tang d-keygen 命令生成 新密钥:

    # /usr/libexec/tangd-keygen /var/db/tang
    # ls /var/db/tang
    3ZWS6-cDrCG61UPJS2BMmPU4I54.jwk zyLuX6hijUy_PSeUEFDi7hi38.jwk
  4. 检查您的 Tang 服务器是否从新密钥对公告签名密钥,例如:

    # tang-show-keys 7500
    3ZWS6-cDrCG61UPJS2BMmPU4I54
  5. 在 NBDE 客户端上,使用 clevis luks report 命令检查 Tang 服务器公告的密钥是否保持不变。您可以使用 clevis luks list 命令标识带有相关绑定的插槽,例如:

    # clevis luks list -d /dev/sda2
    1: tang '{"url":"http://tang.srv"}'
    # clevis luks report -d /dev/sda2 -s 1
    ...
    Report detected that some keys were rotated.
    Do you want to regenerate luks metadata with "clevis luks regen -d /dev/sda2 -s 1"? [ynYN]
  6. 要为新键重新生成 LUKS 元数据,或者在上一个命令提示时按 y,或使用 clevis luks regen 命令:

    # clevis luks regen -d /dev/sda2 -s 1
  7. 当您确定所有旧客户端都使用新密钥时,您可以从 Tang 服务器中删除旧密钥,例如:

    # cd /var/db/tang
    # rm .*.jwk
警告

在客户端仍在使用旧密钥时删除旧密钥可能会导致数据丢失。如果您意外删除了这些密钥,请在客户端上使用 clevis luks regen 命令,并手动提供您的 LUKS 密码。

其它资源

  • tang-show-keys(1)、 clevis-luks-list(1)、 c levis-luks-report(1)和 clevis-luks-regen(1) man page

11.5. 在 web 控制台中使用 Tang 键配置自动解锁

使用 Tang 服务器提供的密钥,配置 LUKS 加密存储设备的自动解锁。

先决条件

  • RHEL 8 web 控制台已安装。

    详情请参阅 安装 Web 控制台

  • cockpit-storaged 软件包安装在您的系统上。
  • cockpit.socket服务运行在9090端口。
  • 已安装 clevist ang 和 clevis-dracut 软件包。
  • Tang 服务器正在运行。

流程

  1. 在 web 浏览器中输入以下地址来打开 RHEL web 控制台:

    https://localhost:9090

    连接到远程系统时,将 localhost 部分替换为远程服务器的主机名或 IP 地址。

  2. 提供您的凭证并点击 Storage。选择加密设备并点 内容部分中的 Encryption
  3. 点击 Keys 部分中的 + 来添加 Tang 键:

    RHEL web 控制台:加密
  4. 提供 Tang 服务器的地址以及用于解锁 LUKS 加密设备的密码。点击 Add 确认:

    RHEL web 控制台:添加 Tang 密钥
  5. 以下对话框窗口提供了 命令,可用于验证密钥哈希是否匹配。RHEL 8.2 引入了 tang-show-keys 脚本,您可以在端口 7500 上运行的 Tang 服务器中使用以下命令来获取密钥哈希:

    # tang-show-keys 7500
    3ZWS6-cDrCG61UPJS2BMmPU4I54

    在 RHEL 8.1 及更早版本中,使用以下命令获取密钥哈希:

    # curl -s localhost:7500/adv | jose fmt -j- -g payload -y -o- | jose jwk use -i- -r -u verify -o- | jose jwk thp -i-
    3ZWS6-cDrCG61UPJS2BMmPU4I54
  6. 当 web 控制台中的密钥哈希值与之前列出的命令的输出中的值相同时,点 Trust key

    RHEL web 控制台:验证 Tang 键
  7. 要启用早期引导系统来处理磁盘绑定,请点击左侧导航栏底部的 Terminal 并输入以下命令:

    # yum install clevis-dracut
    # dracut -fv --regenerate-all

验证

  1. 检查新添加的 Tang 密钥现在是否在 Keys 部分使用 Keyserver 类型列出:

    RHEL web 控制台:列出 keyserver 键
  2. 验证绑定可用于早期引导,例如:

    # lsinitrd | grep clevis
    clevis
    clevis-pin-sss
    clevis-pin-tang
    clevis-pin-tpm2
    -rwxr-xr-x   1 root     root         1600 Feb 11 16:30 usr/bin/clevis
    -rwxr-xr-x   1 root     root         1654 Feb 11 16:30 usr/bin/clevis-decrypt
    ...
    -rwxr-xr-x   2 root     root           45 Feb 11 16:30 usr/lib/dracut/hooks/initqueue/settled/60-clevis-hook.sh
    -rwxr-xr-x   1 root     root         2257 Feb 11 16:30 usr/libexec/clevis-luks-askpass

11.6. 使用 Tang 为 NBDE 系统部署加密客户端

以下流程包含使用 Tang 网络服务器配置加密卷的自动解锁的步骤。

先决条件

  • 已安装 Clevis 框架。
  • Tang 服务器可用。

流程

  1. 要将 Clevis 加密客户端绑定到 Tang 服务器,请使用 clevis encrypt tang 子命令:

    $ clevis encrypt tang '{"url":"http://tang.srv:port"}' < input-plain.txt > secret.jwe
    The advertisement contains the following signing keys:
    
    _OsIk0T-E2l6qjfdDiwVmidoZjA
    
    Do you wish to trust these keys? [ynYN] y

    更改上例中的 http://tang.srv:port URL,使其与安装 tang 的服务器的 URL 匹配。secret.jwe 输出文件包含了您的加密密码文本,采用 JSON Web 加密格式。此密码文本是从 input-plain.txt 输入文件中读取的。

    另外,如果您的配置需要与 Tang 服务器进行非互动通信而无需 SSH 访问,您可以下载公告并将其保存到文件中:

    $ curl -sfg http://tang.srv:port/adv -o adv.jws

    adv.jws 文件中的广播用于任何以下任务,如加密文件或信息:

    $ echo 'hello' | clevis encrypt tang '{"url":"http://tang.srv:port","adv":"adv.jws"}'
  2. 要解密数据,请使用 clevis 解密命令并提供密码文本 (JWE):

    $ clevis decrypt < secret.jwe > output-plain.txt

其它资源

  • clevis-encrypt-tang(1)、 clevis-luks-unlockers(7)clevis(1) man page
  • clevisclevis 解密clevis 加密 tang 命令不带任何参数显示内置 CLI 帮助,例如:

    $ clevis encrypt tang
    Usage: clevis encrypt tang CONFIG < PLAINTEXT > JWE
    ...

11.7. 手动从 LUKS 加密卷中删除 Clevis pin

使用以下步骤手动删除 clevis luks bind 命令创建的元数据,以及擦除包含 Clevis 添加的密码短语的密钥插槽。

重要

从 LUKS 加密卷中删除 Clevis pin 的建议方法是通过 clevis luks unbind 命令。使用 clevis luks unbind 的删除过程仅包含一个步骤,适用于 LUKS1 和 LUKS2 卷。以下示例命令删除绑定步骤创建的元数据,并擦除 /dev/sda2 设备中的键插槽 1

# clevis luks unbind -d /dev/sda2 -s 1

先决条件

  • 具有 Clevis 绑定的 LUKS 加密卷。

流程

  1. 检查卷的 LUKS 版本(如 /dev/sda2 )由 加密,并确定绑定到 Clevis 的插槽和令牌:

    # cryptsetup luksDump /dev/sda2
    LUKS header information
    Version:        2
    ...
    Keyslots:
      0: luks2
    ...
    1: luks2
          Key:        512 bits
          Priority:   normal
          Cipher:     aes-xts-plain64
    ...
          Tokens:
            0: clevis
                  Keyslot:  1
    ...

    在上例中,Clevis 令牌由 0 标识,关联的密钥插槽是 1

  2. 如果使用 LUKS2 加密,请删除令牌:

    # cryptsetup token remove --token-id 0 /dev/sda2
  3. 如果您的设备由 LUKS1 加密,这在 cryptsetup luksDump 命令的输出中由 Version: 1 字符串表示,请使用 the luks meta wipe 命令执行这个额外步骤:

    # luksmeta wipe -d /dev/sda2 -s 1
  4. 擦除包含 Clevis 密码短语的密钥插槽:

    # cryptsetup luksKillSlot /dev/sda2 1

其它资源

  • clevis-luks-unbind(1)、 cryptsetup(8)和 luksmeta(8)man page

11.8. 使用 TPM 2.0 策略部署加密客户端

以下步骤使用受信任的平台模块 2.0(TPM 2.0)策略配置加密卷的自动解锁。

先决条件

流程

  1. 要部署使用 TPM 2.0 芯片加密的客户端,请使用 clevis encrypt tpm2 子命令以及 JSON 配置对象的唯一参数:

    $ clevis encrypt tpm2 '{}' < input-plain.txt > secret.jwe

    要选择不同的层次结构、哈希和关键算法,请指定配置属性,例如:

    $ clevis encrypt tpm2 '{"hash":"sha1","key":"rsa"}' < input-plain.txt > secret.jwe
  2. 要解密数据,以 JSON Web 加密(JWE)格式提供密码文本:

    $ clevis decrypt < secret.jwe > output-plain.txt

pin 还支持将数据封装到平台配置寄存器(PCR)状态。这样,只有 PCRs 哈希值与密封时所用的策略匹配,数据才能被取消密封。

例如,使用 SHA-1 银行的索引 0 和 1 将数据封装到 PCR:

$ clevis encrypt tpm2 '{"pcr_bank":"sha1","pcr_ids":"0,1"}' < input-plain.txt > secret.jwe

其它资源

  • clevis-encrypt-tpm2(1) man page

11.9. 配置 LUKS 加密卷的手动注册

使用以下步骤使用 NBDE 配置 LUKS 加密卷的解锁。

先决条件

  • Tang 服务器正在运行且可用。

流程

  1. 要自动解锁现有的 LUKS 加密卷,请安装 clevis-luks 子软件包:

    # yum install clevis-luks
  2. 识别 PBD 的 LUKS 加密卷。在以下示例中,块设备被指代为 /dev/sda2

    # lsblk
    NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    sda                                             8:0    0    12G  0 disk
    ├─sda1                                          8:1    0     1G  0 part  /boot
    └─sda2                                          8:2    0    11G  0 part
      └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0    0    11G  0 crypt
        ├─rhel-root                               253:0    0   9.8G  0 lvm   /
        └─rhel-swap                               253:1    0   1.2G  0 lvm   [SWAP]
  3. 使用 clevis luks bind 命令将卷绑定到 Tang 服务器:

    # clevis luks bind -d /dev/sda2 tang '{"url":"http://tang.srv"}'
    The advertisement contains the following signing keys:
    
    _OsIk0T-E2l6qjfdDiwVmidoZjA
    
    Do you wish to trust these keys? [ynYN] y
    You are about to initialize a LUKS device for metadata storage.
    Attempting to initialize it may result in data loss if data was
    already written into the LUKS header gap in a different format.
    A backup is advised before initialization is performed.
    
    Do you wish to initialize /dev/sda2? [yn] y
    Enter existing LUKS password:

    此命令执行四个步骤:

    1. 使用与 LUKS 主密钥相同的熵创建新的密钥。
    2. 使用 Clevis 加密新密钥.
    3. 将 Clevis JWE 对象存储在 LUKS2 标头令牌中,或者使用 LUKSMeta(如果使用非默认 LUKS1 标头)。
    4. 启用用于 LUKS 的新密钥。

      注意

      绑定过程假定至少有一个可用的 LUKS 密码插槽。clevis luks bind 命令占用了其中一个插槽。

  4. 卷现在可以使用您的现有密码和 Clevis 策略解锁。
  5. 要启用早期引导系统来处理磁盘绑定,请在已安装的系统中使用 dracut 工具:

    # yum install clevis-dracut

    在 Red Hat Enterprise Linux 8 中,Clevis 生成一个通用 initrd (初始 ramdisk),且没有特定于主机的配置选项,且不会自动在内核命令行中添加诸如 rd.neednet=1 等参数。如果您的配置在早期引导过程中依赖于需要网络的 Tang pin,请在检测到 Tang 绑定时使用 --hostonly-cmdline 参数 and dracut add rd.neednet=1

    # dracut -fv --regenerate-all --hostonly-cmdline

    或者,在 /etc/dracut.conf.d/ 中创建 .conf 文件,并将 hostonly_cmdline=yes 选项添加到该文件中,例如:

    # echo "hostonly_cmdline=yes" > /etc/dracut.conf.d/clevis.conf

    然后您可以在 不使用 --hostonly-cmdline 的情况下使用 racut

    # dracut -fv --regenerate-all

验证

  1. 要验证 Clevis JWE 对象是否已成功放入 LUKS 标头中,请使用 clevis luks list 命令:

    # clevis luks list -d /dev/sda2
    1: tang '{"url":"http://tang.srv:port"}'
重要

要将 NBDE 用于带有静态 IP 配置(没有 DHCP)的客户端,请手动将网络配置传递给 dracut 工具,例如:

# dracut -fv --regenerate-all --kernel-cmdline "ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none:192.0.2.45"

或者,使用静态网络信息在 /etc/dracut.conf.d/ 目录中创建 .conf 文件。例如:

# cat /etc/dracut.conf.d/static_ip.conf
kernel_cmdline="ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none:192.0.2.45"

重新生成初始 RAM 磁盘镜像:

# dracut -fv --regenerate-all

其它资源

  • clevis-luks-bind(1) and dracut.cmdline(7) man pages

11.10. 使用 Kickstart 配置 LUKS 加密卷的自动注册

按照以下步骤配置使用 Clevis 注册 LUKS 加密卷的自动安装过程。

流程

  1. 指示 Kickstart 对磁盘进行分区,以便使用临时密码为所有挂载点(除 /boot )启用了 LUKS 加密。密码是注册过程此步骤的临时密码。

    part /boot --fstype="xfs" --ondisk=vda --size=256
    part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass

    请注意,OSPP-complaint 系统需要更复杂的配置,例如:

    part /boot --fstype="xfs" --ondisk=vda --size=256
    part / --fstype="xfs" --ondisk=vda --size=2048 --encrypted --passphrase=temppass
    part /var --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
    part /tmp --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
    part /home --fstype="xfs" --ondisk=vda --size=2048 --grow --encrypted --passphrase=temppass
    part /var/log --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
    part /var/log/audit --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
  2. 通过在 %packages 部分列出相关的 Clevis 软件包来安装相关的 Clevis 软件包:

    %packages
    clevis-dracut
    %end
  3. %post 部分中调用 clevis luks bind 以执行绑定。之后,删除临时密码:

    %post
    curl -sfg http://tang.srv/adv -o adv.jws
    clevis luks bind -f -k- -d /dev/vda2 \
    tang '{"url":"http://tang.srv","adv":"adv.jws"}' \ <<< "temppass"
    cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
    %end

    在上例中,请注意,我们从 Tang 服务器下载广播,作为绑定配置的一部分,启用绑定完全非交互式。

    警告

    cryptsetup luksRemoveKey 命令可以防止对应用该命令的 LUKS2 设备进行任何进一步的管理。您只能对 LUKS1 设备使用 dmsetup 命令恢复移除的 master 密钥。

在使用 TPM 2.0 策略而不是 Tang 服务器时,您可以使用类似的步骤。

其它资源

11.11. 配置 LUKS 加密可移动存储设备的自动解锁

使用这个流程设置 LUKS 加密 USB 存储设备的自动解锁过程。

流程

  1. 要自动解锁 LUKS 加密的可移动存储设备,如 USB 驱动器,请安装 clevis-udisks2 软件包:

    # yum install clevis-udisks2
  2. 重启系统,然后使用 clevis luks bind 命令执行绑定步骤,如 配置 LUKS 加密卷的手动注册 中所述,例如:

    # clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'
  3. 现在,可以在 GNOME 桌面会话中自动解锁 LUKS 加密的可移动设备。绑定到 Clevis 策略的设备也可以通过 clevis luks unlock 命令解锁

    # clevis luks unlock -d /dev/sdb1

在使用 TPM 2.0 策略而不是 Tang 服务器时,您可以使用类似的步骤。

其它资源

  • clevis-luks-unlockers(7) man page

11.12. 部署高可用性 NBDE 系统

Tang 提供两种构建高可用性部署的方法:

客户端冗余(推荐)
客户端应配置为绑定到多个 Tang 服务器。在此设置中,每个 Tang 服务器都有自己的密钥,客户端可以通过联系这些服务器的子集来进行解密。Clevis 已通过其 sss 插件支持此工作流。红帽建议在高可用性部署中使用这个方法。
密钥共享
出于冗余目的,可以部署多个 Tang 实例。要设置第二个或后续的实例,请安装 tang 软件包,并通过 SSH 将密钥目录复制到新主机上。请注意,红帽不推荐此方法,因为共享密钥会增加关键威胁的风险,需要额外的自动化基础架构。

11.12.1. 使用 Shamir 的 Secret Sharing 的高可用性 NBDE

Shamir 的 Secret 共享(SSS)是一种加密方案,可将机密划分为多个唯一部分。要重建 secret,需要一些部分。该数字称为阈值,SSS 也被称为阈值方案。

Clevis 提供 SSS 实施。它创建了密钥,并将其分为若干个片段。每个片段都使用另一个 pin 进行加密,包括递归 SSS。另外,您可以定义阈值 t。如果 NBDE 部署至少解密了 t 个 片段,则会恢复加密密钥,解密过程会成功。当 Clevis 检测到比阈值中指定的更少的部分时,它会打印错误消息。

11.12.1.1. 示例 1:两个 Tang 服务器冗余

当至少有两个 Tang 服务器之一可用时,以下命令解密 LUKS 加密设备:

# clevis luks bind -d /dev/sda1 sss '{"t":1,"pins":{"tang":[{"url":"http://tang1.srv"},{"url":"http://tang2.srv"}]}}'

上一命令使用以下配置方案:

{
    "t":1,
    "pins":{
        "tang":[
            {
                "url":"http://tang1.srv"
            },
            {
                "url":"http://tang2.srv"
            }
        ]
    }
}

在此配置中,SSS 阈值 t 设置为 1,如果至少有两个列出的 tang 服务器中有一台,clevis luks bind 命令可以成功重建 secret。

11.12.1.2. 示例 2:Tang 服务器中的共享 secret 和 TPM 设备

tang 服务器和 tpm2 设备都可用时,以下命令成功解密 LUKS 加密设备:

# clevis luks bind -d /dev/sda1 sss '{"t":2,"pins":{"tang":[{"url":"http://tang1.srv"}], "tpm2": {"pcr_ids":"0,1"}}}'

SSS threshold 't' 设置为 '2' 的配置方案现在是:

{
    "t":2,
    "pins":{
        "tang":[
            {
                "url":"http://tang1.srv"
            }
        ],
        "tpm2":{
            "pcr_ids":"0,1"
        }
    }
}

其它资源

  • Tang(8) (章节 高可用性)、c levis(1)Shamir 的 Secret Sharing部分)和 clevis-encrypt-sss(1) man page

11.13. 在 NBDE 网络中部署虚拟机

clevis luks bind 命令不会改变 LUKS 主密钥。这意味着,如果您创建 LUKS 加密镜像以在虚拟机或云环境中使用,则运行此镜像的所有实例都将共享主密钥。这极其不安全,应始终避免。

这不是 Clevis 的一个限制,而是 LUKS 的设计原则。如果您要在云中加密根卷,则需要确保为云中的每个 Red Hat Enterprise Linux 实例执行安装过程(通常使用 Kickstart)。如果没有同时共享 LUKS 主密钥,就无法共享镜像。

如果您要在虚拟化环境中部署自动解锁,红帽强烈建议您将 lorax 或 virt-install 等系统与 Kickstart 文件一起使用(请参阅 使用 Kickstart 配置 LUKS 加密卷自动注册)或其他自动配置工具,以确保每个加密的虚拟机都有一个唯一的 master 密钥。

注意

虚拟机不支持使用 TPM 2.0 策略自动解锁。

其它资源

  • clevis-luks-bind(1) man page

11.14. 使用 NBDE 为云环境构建可自动滚动的虚拟机镜像

在云环境中部署可自动滚动的加密镜像会提供一套独特的挑战。与其他虚拟化环境一样,建议减少从单个镜像启动的实例数量,以避免共享 LUKS 主密钥。

因此,最佳实践是创建自定义映像,这些映像不在任何公共存储库中共享,为部署有限数量实例提供基础。要创建的实例的确切数量应当通过部署的安全策略来定义,并且基于与 LUKS 主密钥攻击向量关联的风险容错能力。

要构建启用 LUKS 的自动化部署,应当使用 Lorax 或 virt-install 和 Kickstart 文件等系统来确保镜像构建过程中具有主密钥独有性。

云环境启用两个我们在此处考虑的 Tang 服务器部署选项。首先,Tang 服务器可以在云环境本身中部署。其次,Tang 服务器可以在独立的基础架构上部署在云外,并在两个基础架构之间使用 VPN 链接进行部署。

在云中原生部署 Tang 有助于轻松部署。但是,由于它与其他系统的数据持久性层共享基础架构,因此 Tang 服务器的私钥和 Clevis 元数据可以存储在同一个物理磁盘上。访问此物理磁盘可以完全损坏密码文本数据。

重要

因此,红帽强烈建议在存储数据的位置和运行 Tang 的系统之间保持物理隔离。这种云和 Tang 服务器之间的这种隔离可确保 Tang 服务器的私钥不会被意外与 Clevis 元数据组合。如果云基础架构面临风险,它还提供 Tang 服务器的本地控制。

11.15. 将 Tang 部署为容器

rhel8-tang 容器镜像为在 OpenShift Container Platform (OCP) 集群或单独的虚拟机中运行的 Clevis 客户端提供 Tang-server 解密功能。

先决条件

  • podman 软件包及其依赖项安装在系统上。
  • 已使用 podman login registry.redhat.io 命令登录到 registry.redhat.io 容器目录。如需更多信息,请参阅 Red Hat Container Registry 身份验证
  • Clevis 客户端安装在包含 LUKS 加密卷的系统上,您希望使用 Tang 服务器自动解锁这些卷。

流程

  1. 从 registry. redhat.io registry 中拉取 rhel8-tang 容器镜像:

    # podman pull registry.redhat.io/rhel8/rhel8-tang
  2. 运行容器,指定其端口,并指定到 Tang 密钥的路径。以上示例运行 rhel8-tang 容器,指定端口 7500,并指明到 /var/db/tang 目录的 Tang 密钥的路径:

    # podman run -d -p 7500:_7500_ -v tang-keys:/var/db/tang --name tang registry.redhat.io/rhel8/rhel8-tang

    请注意,Tang 默认使用端口 80,但这可能与 Apache HTTP 服务器等其他服务冲突。

  3. [可选] 为提高安全性,定期轮转 Tang 密钥。您可以使用 tangd-rotate-keys 脚本,例如:

    # podman run --rm -v tang-keys:/var/db/tang registry.redhat.io/rhel8/rhel8-tang tangd-rotate-keys -v -d /var/db/tang
    Rotated key 'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk' -> .'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk'
    Rotated key 'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk' -> .'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk'
    Created new key GrMMX_WfdqomIU_4RyjpcdlXb0E.jwk
    Created new key _dTTfn17sZZqVAp80u3ygFDHtjk.jwk
    Keys rotated successfully.

验证

  • 在包含 LUKS 加密卷的系统上,通过存在 Tang 服务器自动解锁,检查 Clevis 客户端是否可以使用 Tang 加密和解密纯文本消息:

    # echo test | clevis encrypt tang '{"url":"http://localhost:_7500_"}' | clevis decrypt
    The advertisement contains the following signing keys:
    
    x1AIpc6WmnCU-CabD8_4q18vDuw
    
    Do you wish to trust these keys? [ynYN] y
    test

    localhost URL 上有 Tang 服务器可用并通过端口 7500 通信时,上一示例命令显示在其输出末尾的 test 字符串。

其它资源

  • podman(1)、 clevis(1)和 tang(8)man page

11.16. Clevis 和 Tang 系统角色介绍

RHEL 系统角色是 Ansible 角色和模块的集合,可为远程管理多个 RHEL 系统提供一致的配置界面。

RHEL 8.3 在使用 Clevis 和 Tang 自动部署基于策略的 Decryption(PBD)解决方案时引入了 Ansible 角色。rhel-system-roles 包中包含了这些系统角色、相关的例子以及参考文档。

nbde_client 系统角色使您能够以自动化的方式部署多个Clevis客户端。请注意,nbde_client 角色只支持 Tang 绑定,您目前无法将其用于 TPM2 绑定。

nbde_client 角色需要已经使用 LUKS 加密的卷。此角色支持将 LUKS 加密卷绑定到一个或多个 Network-Bound(NBDE)服务器 - Tang 服务器。您可以使用密码短语保留现有卷加密,或者将其删除。删除密码短语后,您只能使用 NBDE 解锁卷。这在最初使用您置备系统后应删除的临时密钥或密码加密卷时很有用。

如果您同时提供密语和密钥文件,该角色将使用您首先提供的内容。如果找不到任何有效密码,它将尝试从现有的绑定中检索密码短语。

PBD 将绑定定义为设备与插槽的映射。这意味着您可以在同一设备上有多个绑定。默认插槽是插槽 1。

nbde_client 角色也提供了 state 变量。使用 当前 值创建新绑定或更新现有绑定。与 clevis luks bind 命令不同,您可以使用 state: present 来覆盖其设备插槽中的现有绑定。absent 的值会删除指定的绑定。

使用 nbde_server 角色,您可以部署和管理 Tang 服务器作为自动磁盘加密解决方案的一部分。此角色支持以下功能:

  • 轮转 Tang 密钥
  • 部署和备份 Tang 密钥

其它资源

  • 有关 Network-Bound Disk Encryption(NBDE)角色变量的详细参考,请安装 rhel-system-roles 软件包,并参阅 /usr/share/doc/rhel-system-roles/nbde_client/ 和 /usr/share/doc/rhel- system-roles/nbde_server/ 目录的 README.md 和README.html 文件。
  • 例如,system-roles playbook、安装 rhel-system-roles 软件包,并查看 /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ 目录。
  • 有关 RHEL 系统角色的更多信息,请参阅 RHEL 系统角色简介

11.17. 使用 nbde_server 系统角色设置多个 Tang 服务器

按照以下步骤准备并应用包含您的 Tang-server 设置的 Ansible playbook。

先决条件

流程

  1. 启用 RHEL Ansible 存储库,例如:

    # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
  2. 安装 Ansible Engine:

    # yum install ansible
  3. 安装 RHEL 系统角色:

    # yum install rhel-system-roles
  4. 准备包含 Tang 服务器设置的 playbook。您可以从头开始,或使用 /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ 目录中的一个示例 playbook。

    # cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml
  5. 在您选择的文本编辑器中编辑 playbook,例如:

    # vi my-tang-playbook.yml
  6. 添加所需参数。以下示例 playbook 确保部署 Tang 服务器和密钥轮转:

    ---
    - hosts: all
    
      vars:
        nbde_server_rotate_keys: yes
    
      roles:
        - linux-system-roles.nbde_server
  7. 应用完成的 playbook:

    # ansible-playbook -i host1,host2,host3 my-tang-playbook.yml

其它资源

  • 如需更多信息,请安装 rhel-system-roles 软件包,并查看 /usr/share/doc/rhel-system-roles/nbde_server/usr/share/ansible/roles/rhel-system-roles.nbde_server/ 目录。

11.18. 使用 nbde_client 系统角色设置多个 Clevis 客户端

按照以下步骤准备并应用包含 Clevis-client 设置的 Ansible playbook。

注意

nbde_client 系统角色只支持 Tang 绑定。这意味着您目前无法将其用于 TPM2 绑定。

先决条件

流程

  1. 启用 RHEL Ansible 存储库,例如:

    # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
  2. 安装 Ansible Engine:

    # yum install ansible
  3. 安装 RHEL 系统角色:

    # yum install rhel-system-roles
  4. 准备包含 Clevis 客户端设置的 playbook。您可以从头开始,或使用 /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/ 目录中的一个示例 playbook。

    # cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml
  5. 在您选择的文本编辑器中编辑 playbook,例如:

    # vi my-clevis-playbook.yml
  6. 添加所需参数。以下示例 playbook 配置 Clevis 客户端,以便在至少两个 Tang 服务器之一可用时自动解锁两个 LUKS 加密卷:

    ---
    - hosts: all
    
      vars:
        nbde_client_bindings:
          - device: /dev/rhel/root
            encryption_key_src: /etc/luks/keyfile
            servers:
              - http://server1.example.com
              - http://server2.example.com
          - device: /dev/rhel/swap
            encryption_key_src: /etc/luks/keyfile
            servers:
              - http://server1.example.com
              - http://server2.example.com
    
      roles:
        - linux-system-roles.nbde_client
  7. 应用完成的 playbook:

    # ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml

其它资源

  • 有关 nbde_client 角色的参数和其他信息,安装 rhel-system-roles 软件包,并查看 /usr/share/doc/rhel-system-roles/nbde_client/ 和 /usr/ share/ansible/roles/rhel-system-roles.nbde_client/ 目录。

11.19. 其它资源

第 12 章 审核系统

Audit 不会为您的系统提供额外的安全性,而是可用于发现系统上使用的安全策略违规。通过 SELinux 等其他安全措施可以进一步阻止这些冲突。

12.1. Linux Audit

Linux Audit 系统提供了一种方式来跟踪系统中的安全相关信息。根据预配置的规则,审计会生成日志条目,以记录有关系统上发生事件的尽可能多的信息。对于关键任务环境而言,此信息对于确定安全策略的违反者及其执行的操作至关重要。

以下列表总结了审计可以在其日志文件中记录的一些信息:

  • 事件的日期和时间、类型和结果.
  • 主题和对象的敏感度标签。
  • 事件与触发事件的用户的身份相关联。
  • 对 Audit 配置的所有修改,并尝试访问 Audit 日志文件。
  • 所有身份验证机制的使用,如 SSH 和 Kerberos 等。
  • 对任何受信任数据库的更改,如 /etc/passwd.
  • 尝试从系统导入或导出信息.
  • 根据用户身份、主题和对象标签以及其他属性,包含或排除事件。

使用审计系统也是许多安全相关认证的一项要求。审计旨在满足或超过以下认证或合规指南的要求:

  • 受控访问保护配置文件(CAPP)
  • 标记的安全保护配置文件(LSPP)
  • 规则集基本访问控制(RSBAC)
  • 国家工业安全计划操作手册(NISPOM)
  • 联邦信息安全管理法案(FISMA)
  • 支付卡行业 - 数据安全标准(PCI-DSS)
  • 安全技术实施指南(STIG)

审计还包括:

  • 由国家信息保障合作伙伴(NIAP)和最佳安全行业(BSI)评估。
  • 通过红帽企业 Linux 5 上的 LSPP/CAPP/RSBAC/EAL4+ 认证.
  • 红帽企业 Linux 6 上经过操作系统保护配置文件/评估保证级别 4+(OSPP/EAL4+)认证.

使用案例

监视文件访问
审计可以跟踪文件或目录是否已访问、修改、执行或文件属性是否已更改。例如,这可用于检测对重要文件的访问,并在其中一个文件损坏时提供审计跟踪。
监控系统调用
可将审计配置为在每次使用特定系统调用时生成日志条目。例如,这可用于通过监控 settimeofday、clock_adjtime 和其他时间相关系统调用来跟踪系统时间的更改。
记录用户运行的命令
审计可以跟踪文件是否已执行,因此可以定义规则以记录特定命令的每次执行。例如,可以为 /bin 目录中的每个可执行文件定义规则。然后,可以按用户 ID 搜索生成的日志条目,以生成每个用户所执行命令的审计跟踪。
记录系统路径名称的执行
除了观察在规则调用时转换索引节点路径的文件访问之外,审计现在还可以观察路径的执行,即使路径在规则调用中不存在,或者在规则调用后替换了文件。这允许规则在升级程序可执行文件或甚至安装之前继续运行。
记录安全事件
pam_faillock 认证模块能够记录失败的登录尝试。也可以将审计设置为记录失败的登录尝试,并提供试图登录的用户的附加信息。
搜索事件
Audit 提供 ausearch 实用程序,可用于过滤日志条目并根据多个条件提供完整的审计跟踪。
运行摘要报告
aureport 实用程序可用于生成记录事件的日常报告等。然后,系统管理员可以分析这些报告,并进一步调查可疑活动。
监控网络访问
iptablesebtables 实用程序可以配置为触发审计事件,允许系统管理员监控网络访问。
注意

系统性能可能会受到影响,具体取决于审计收集的信息数量。

12.2. Audit 系统架构

Audit 系统由两个主要部分组成:用户空间应用程序和实用程序,以及内核端系统调用处理。内核组件从用户空间应用程序接收系统调用,并通过以下过滤器之一对其进行过滤:用户、任务、fstypeexit

系统调用通过 exclude 过滤器后,它将通过上述其中一个过滤器发送,这些过滤器根据 Audit 规则配置将其发送到 Audit 守护进程,以进行进一步处理。

用户空间审计守护进程从内核收集信息,并在日志文件中创建条目。其他 Audit 用户空间实用程序与 Audit 守护进程、内核审计组件或 Audit 日志文件交互:

  • auditctl - Audit 控制实用程序与内核审计组件交互,以管理规则并控制事件生成进程的许多设置和参数。
  • 剩余的 Audit 实用程序将 Audit 日志文件的内容作为输入,并根据用户的要求生成输出。例如,aureport 实用程序生成所有记录事件的报告。

在 RHEL 8 中,审计分配程序守护进程(audisp)功能集成在 Audit 守护进程(auditd)中。用于实时分析程序与 Audit 事件交互的插件配置文件默认位于 /etc/audit/plugins.d/ 目录中。

12.3. 为安全的环境配置 auditd

默认 auditd 配置应当适合大多数环境。但是,如果您的环境必须满足严格的安全策略,建议在 /etc/audit/auditd.conf 文件中对 Audit 守护进程配置进行以下设置:

log_file
包含 Audit 日志文件的目录(通常为 /var/log/audit/)应位于单独的挂载点。这可以防止其他进程消耗此目录中的空间,并为 Audit 守护进程提供准确检测剩余空间。
max_log_file
指定单个审计日志文件的最大大小,必须设置该文件才能充分利用保存审计日志文件的分区上的可用空间。
max_log_file_action
决定在 max_log_file 中设置限制后执行的操作,应设置为 keep_logs,以防止覆盖 Audit 日志文件。
space_left
指定磁盘上触发 space_left_action 参数中设置操作的可用空间量。必须设置一个数字,让管理员有足够的时间来响应和释放磁盘空间。space_left 的值取决于审计日志文件的生成速度。
space_left_action
建议使用适当的通知方法将 space_left_action 参数设置为 emailexec
admin_space_left
指定在 admin_space_left_action 参数中设置的操作的绝对最小可用空间量,必须设置为保留足够空间以记录管理员执行的操作的值。
admin_space_left_action
应将 设置为 single 以将系统置于单用户模式并允许管理员释放一些磁盘空间。
disk_full_action
指定在保存 Audit 日志文件的分区上没有可用空间时触发的操作,必须设置为 haltsingle。当 Audit 无法记录事件时,这可确保系统以单用户模式关闭或运行。
disk_error_action
指定在包含 Audit 日志文件的分区上检测到错误时触发的操作,必须设置为 syslog单一 或停止 具体取决于您处理硬件故障的本地安全策略。
flush
应设置为 incremental_async。它与 freq 参数相结合,该参数决定了在强制与硬盘进行硬盘同步前可以将多少条记录发送到磁盘。freq 参数应设置为100。这些参数可确保审计事件数据与磁盘上的日志文件同步,同时保持良好的活动性能。

其余配置选项应根据您的本地安全策略设置。

12.4. 启动和控制 auditd

配置了 auditd 后,启动服务以收集审计信息并将其存储在日志文件中。以 root 用户身份运行以下命令启动 auditd

service auditd start

auditd 配置为在引导时启动

systemctl enable auditd

可以使用 service auditd action 命令对 auditd 执行许多其他操作,其中 action 可以是以下之一:

stop
停止 auditd
restart
重新启动 auditd
reloadforce-reload
/etc/audit/auditd.conf 文件中重新加载 auditd 的配置
rotate
轮转 /var/log/audit/ 目录中的日志文件。
resume
在之前暂停后恢复审计事件记录,例如,当保存 Audit 日志文件的磁盘分区中没有足够的可用空间时。
condrestarttry-restart
只有在 auditd 已在运行时才重新启动。
status
显示 auditd 的运行状态
注意

service命令是与 auditd 守护进程正确交互的唯一方法。您需要使用 service 命令,以便正确记录 auid 值。您只能将 systemctl 命令用于两个操作: enablestatus

12.5. 了解 Audit 日志文件

默认情况下,审计系统将日志条目存储在 /var/log/audit/audit.log 文件中;如果启用了日志轮转,则轮转 audit.log 文件存储在同一个目录中。

添加以下审计规则,记录每次尝试读取或修改 /etc/ssh/sshd_config 文件:

# auditctl -w /etc/ssh/sshd_config -p warx -k sshd_config

如果 auditd 守护进程正在运行,例如使用以下命令在 Audit 日志文件中创建新事件:

cat /etc/ssh/sshd_config

audit.log 文件中的该事件如下。

type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"
type=CWD msg=audit(1364481363.243:24287):  cwd="/home/shadowman"
type=PATH msg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0  nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1364481363.243:24287) : proctitle=636174002F6574632F7373682F737368645F636F6E666967

以上事件由四个记录组成,它们共享相同的时间戳和序列号。记录始终以 type= 关键字开头。每个记录由多个 name=值对 组成,值对由空格或逗号分开。对上述事件的详细分析如下:

第一次记录

type=SYSCALL
type 字段包含记录的类型。在本例中,SYSC ALL 值指定此记录是由系统调用对内核触发的。
msg=audit(1364481363.243:24287):

msg 字段记录:

  • 时间戳和记录的唯一 ID,格式为 audit(time_stamp:ID)。如果多个记录是作为同一审计事件的一部分生成的,则可以共享相同的时间戳和 ID。时间戳在 1970 年 1 月 1 日使用 Unix 时间格式 - 秒,自 00:00:00 UTC 起。
  • 各种特定于事件 的名称= 内核或用户空间应用程序提供的值对.
arch=c000003e
arch 字段包含系统的 CPU 架构信息。该值 c000003e 以十六进制表示法编码。使用 ausearch 命令搜索 Audit 记录时,请使用 -i 或 --interpret 选项自动将十六进制值转换为其人类可读的等效值。c000003e 值被解释为 x86_64
syscall=2
syscall字段记录了发送到内核的系统调用的类型。值 2 可以与其 /usr/include/asm/unistd_64.h 文件中的人类可读等效值匹配。在本例中,2open 系统调用。请注意,ausyscall 实用程序允许您将系统调用号转换为其人类可读的等效项。使用 ausyscall --dump 命令显示所有系统调用的列表及其编号。如需更多信息,请参阅 ausyscall(8)man page。
success=no
success 字段记录了该特定事件中记录的系统调用是成功还是失败。在这种情况下,调用没有成功。
exit=-13

exit 字段包含一个值,指定系统调用返回的退出代码。此值因不同的系统调用而异。您可以使用以下命令将值解读为其人类可读的等效值:

ausearch --interpret --exit -13

请注意,上例假定您的审计日志包含带有退出代码 -13 的事件。

a0=7fffd19c5592, a1=0, a2=7fffd19c5592, a3=a
a0a3字段记录了该事件中系统调用的前四个参数,用十六进制符号编码。这些参数取决于使用的系统调用,可以通过 ausearch 实用程序来解释。
items=1
items 字段包含系统调用记录后面的 PATH 辅助记录的数量。
ppid=2686
ppid 字段记录了父进程ID(PPID)。在这种情况下,2686 是父进程的 PPID,如 bash
pid=3538
pid 字段记录了流程 ID(PID)。在本例中,3538cat 进程的 PID。
auid=1000
auid字段记录了审计用户 ID,即loginuid。此 ID 在登录时分配给用户,并在每次用户的身份更改时继承,例如使用 su - john 命令切换用户帐户。
uid=1000
uid 字段记录了启动分析过程的用户的用户 ID。使用以下命令可以解读用户 ID:ausearch -i --uid UID.
gid=1000
gid 字段记录了启动分析过程的用户的组 ID。
euid=1000
euid 字段记录了启动分析过程的用户的有效用户 ID。
suid=1000
suid 字段记录了启动分析过程的用户的设置用户 ID。
fsuid=1000
fsuid 字段记录了启动分析进程的用户的文件系统用户 ID。
egid=1000
egid 字段记录了启动分析过程的用户的有效组 ID。
sgid=1000
sgid 字段记录了启动分析过程的用户的组 ID。
fsgid=1000
fsgid 字段记录了启动分析进程的用户的文件系统组 ID。
tty=pts0
tty 字段记录了分析过程被调用的终端。
ses=1
ses 字段记录了分析过程被调用的会话的会话 ID。
comm="cat"
comm 字段记录了用于调用分析过程的命令行名称。在本例中,cat 命令用于触发此审计事件
exe="/bin/cat"
exe 字段记录了用于调用分析过程的可执行文件的路径。
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
subj 字段记录了被分析的进程在执行时被标记的 SELinux 上下文。
key="sshd_config"
key 记录了与在审计日志中生成该事件的规则相关联的管理员定义的字符串。

第二记录

type=CWD

在第二条记录中,type 字段值为 CWD - 当前工作目录。此类型用于记录从中调用第一条记录中指定的系统调用的进程的工作目录。

此记录的目的是记录当前进程的位置,以便在相关 PATH 记录中捕获相对路径。这样,可以重建绝对路径。

msg=audit(1364481363.243:24287)
msg 字段持有与第一条记录中的值相同的时间戳和 ID 值。时间戳在 1970 年 1 月 1 日使用 Unix 时间格式 - 秒,自 00:00:00 UTC 起。
cwd="/home/user_name"
cwd 字段包含系统调用所在目录的路径。

第三个记录

type=PATH
在第三条记录中,type 字段值为 PATH。Audit 事件包含作为参数传递给系统调用的每个路径的 PATH-type 记录。在这个审计事件中,只有一个路径(/etc/ssh/sshd_config)作为参数。
msg=audit(1364481363.243:24287):
msg 字段拥有与第一和第二条记录中的值相同的时间戳和 ID 值。
item=0
item 字段表示在 SYSCALL 类型记录所引用的项目总数中,当前记录是哪个项目。这个数字基于零;值 0 表示它是第一项。
name="/etc/ssh/sshd_config"
name 字段记录了作为参数传递给系统调用的文件或目录的路径。在本例中,它是 /etc/ssh/sshd_config 文件。
inode=409248

inode 字段包含与该事件中记录的文件或目录相关联的 inode 号。以下命令显示与 409248 索引节点编号关联的文件或目录:

find / -inum 409248 -print
/etc/ssh/sshd_config
dev=fd:00
dev 字段指定了包含该事件中记录的文件或目录的设备的次要和主要 ID。在本例中,值表示 /dev/fd/0 设备。
mode=0100600
mode 字段记录文件或目录权限,由数字标记。它是 st_mode 字段中的 stat 命令返回。如需更多信息,请参阅 stat(2) man page。在这种情况下,0100600 可以解释为 -rw-------,这意味着只有 root 用户对 /etc/ssh/sshd_config 文件具有读取和写入权限。
ouid=0
ouid 字段记录了对象所有者的用户 ID。
ogid=0
ogid 字段记录了对象所有者的组 ID。
rdev=00:00
rdev 字段包含一个记录的设备标识符,仅用于特殊文件。在这种情况下,不会使用它,因为记录的文件是常规文件。
obj=system_u:object_r:etc_t:s0
obj 字段记录了 SELinux 上下文,在执行时,记录的文件或目录被贴上了标签。
nametype=NORMAL
nametype 字段记录了每个路径记录在给定系统调用的上下文中的操作意图。
cap_fp=none
cap_fp 字段记录了与设置文件或目录对象的基于文件系统的允许能力有关的数据。
cap_fi=none
cap_fi 字段记录了与文件或目录对象的基于继承文件系统的能力设置有关的数据。
cap_fe=0
cap_fe 字段记录了文件或目录对象基于文件系统能力的有效位的设置。
cap_fver=0
cap_fver 字段记录了文件或目录对象基于文件系统能力的版本。

第四个记录

type=PROCTITLE
type 字段包含记录的类型。在本例中,PROCTITLE 值指定此记录提供触发此审计事件的完整命令行,该事件由对内核的系统调用触发。
proctitle=636174002F6574632F7373682F737368645F636F6E666967
proctitle 字段记录了用于调用分析过程的命令的完整命令行。该字段采用十六进制表示法编码,不允许用户影响 Audit 日志解析器。文本解码到触发此审计事件的命令。使用 ausearch 命令搜索 Audit 记录时,请使用 -i 或 --interpret 选项自动将十六进制值转换为其人类可读的等效值。636174002F6574632F7373682F737368645F636F6E666967 值解释为 cat /etc/ssh/sshd_config

12.6. 使用 auditctl 定义和执行审计规则

Audit 系统在一组规则上运行,这些规则定义日志文件中捕获的内容。可以使用 auditctl 实用程序在命令行中或使用 /etc/audit/rules.d/ 目录中设置审计规则。

auditctl 命令使您能够控制审计系统的基本功能,并定义决定记录哪些审计事件的规则。

文件系统规则示例

  1. 要定义一条规则,记录 /etc/passwd 文件的所有写入访问权限和每个属性更改:

    # auditctl -w /etc/passwd -p wa -k passwd_changes
  2. 要定义一条规则,记录对 /etc/selinux/ 目录中所有文件的写入访问和每个属性更改:

    # auditctl -w /etc/selinux/ -p wa -k selinux_changes

系统调用规则示例

  1. 要定义当程序每次使用 adjtimexsettimeofday 系统调用时创建日志条目的规则,系统使用 64 位构架:

    # auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
  2. 定义一个规则,在每次删除文件时创建一个日志条目,或者由 ID 为 1000 或以上的系统用户重命名:

    # auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

    请注意,-F auid!=4294967295 选项用于排除未设置登录 UID 的用户。

可执行文件规则

要定义记录所有 /bin/id 程序执行的规则,请执行以下命令:

# auditctl -a always,exit -F exe=/bin/id -F arch=b64 -S execve -k execution_bin_id

其它资源

  • audictl(8) 手册页.

12.7. 定义持久性审计规则

要定义在重启过程中保持不变的审计规则,必须直接将其包含在 /etc/audit/rules.d/audit.rules 文件中,或者使用 augenrules 程序读取位于/etc/audit/rules.d/ 目录中的规则。

请注意,每次 auditd 服务启动时都会生成 /etc/audit/audit.rules 文件。/etc/audit/rules.d/ 中的文件使用相同的 auditctl 命令行语法来指定规则。哈希符号(#)后面的空行和文本将被忽略。

另外,您可以使用 auditctl 命令使用 -R 选项从指定文件中读取规则,例如:

# auditctl -R /usr/share/audit/sample-rules/30-stig.rules

12.8. 使用预配置的规则文件

/usr/share/audit/sample-rules 目录中,审计 软件包根据各种认证标准提供一组预配置的规则文件:

30-nispom.rules
满足国家工业安全计划操作手册"信息系统安全"一章中指定的要求的审计规则配置.
30-ospp-v42*.rules
满足 OSPP(通用目的操作系统)配置集版本 4.2 中定义的要求的审计规则配置。
30-pci-dss-v31.rules
满足支付卡行业数据安全标准(PCI DSS)v3.1 要求的审计规则配置。
30-stig.rules
满足安全技术实施指南(STIG)要求的审计规则配置。

要使用这些配置文件,将其复制到 /etc/audit/rules.d/ 目录中,并使用 augenrules --load 命令,例如:

# cd /usr/share/audit/sample-rules/
# cp 10-base-config.rules 30-stig.rules 31-privileged.rules 99-finalize.rules /etc/audit/rules.d/
# augenrules --load

您可以使用编号方案订购审计规则。如需更多信息,请参阅 /usr/share/audit/sample-rules/README-rules 文件。

其它资源

  • audit.rules(7) 手册页.

12.9. 使用 augenrules 定义持久性规则

augenrules脚本读取位于/etc/audit/rules.d/目录下的规则,并将它们编译成audit.rures文件。这个脚本会根据自然的排序顺序按特定顺序处理以 .rules 结尾的所有文件。这个目录中的文件被组织到组中,其含义如下:

  • 10 - 内核和 auditctl 配置
  • 20 - 可与常规规则匹配但您希望不同匹配的规则
  • 30 - 主要规则
  • 40 - 可选规则
  • 50 - 服务器特定规则
  • 70 - 系统本地规则
  • 90 - 结束(不可变)

规则并非是一次性全部使用。它们是策略的一部分,应仔细考虑,并将单个文件复制到 /etc/audit/rules.d/。例如,要在 STIG 配置中设置系统,复制规则 10-base-config、30- stig31-privileged99-finalize

/etc/audit/rules.d/ 目录中有规则后,使用 --load 指令运行 augenrules 脚本来加载它们:

# augenrules --load
/sbin/augenrules: No change
No rules
enabled 1
failure 1
pid 742
rate_limit 0
...

其它资源

  • audit.rules(8)和 augenrules(8)man page。

12.10. 禁用 augenrules

使用以下步骤禁用 augenrules 工具程序。这会将 Audit 切换为使用 /etc/audit/audit.rules 文件中定义的规则。

流程

  1. /usr/lib/systemd/system/auditd.service 文件复制到 /etc/systemd/system/ 目录中:

    # cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/
  2. 在您选择的文本编辑器中编辑 /etc/systemd/system/auditd.service 文件,例如:

    # vi /etc/systemd/system/auditd.service
  3. 注释掉包含 augenrules 的行,取消注释包含 auditctl -R 命令的 行:

    #ExecStartPost=-/sbin/augenrules --load
    ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
  4. 重新载入 systemd 守护进程以获取 auditd.service 文件中的更改:

    # systemctl daemon-reload
  5. 重启 auditd 服务:

    # service auditd restart

其它资源

第 13 章 使用 fapolicyd 阻塞和允许应用程序

设置和强制实施允许或拒绝基于规则集的应用执行策略可有效防止执行未知和潜在恶意软件。

13.1. fapolicyd 简介

fapolicyd软件框架根据用户定义的策略来控制应用程序的执行。这是防止在系统上运行不受信任和可能恶意应用程序的最有效方法之一。

fapolicyd 框架提供以下组件。

  • fapolicyd 服务
  • fapolicyd 命令行工具
  • fapolicyd RPM 插件
  • fapolicyd 规则语言

管理员可以为任何应用定义 允许拒绝执行 规则,并可基于路径、散列、MIME 类型或信任进行审计。

fapolicyd 框架引入了信任的概念。应用程序在系统软件包管理器正确安装时是可信的,因此它在系统 RPM 数据库中进行了注册。fapolicyd 守护进程使用 RPM 数据库作为受信任的二进制文件和脚本的列表。fapolicyd RPM 插件注册由 YUM 软件包管理器或 RPM 软件包管理器处理的任何系统更新。插件通知 fapolicyd 守护进程此数据库中的更改。添加应用程序的其他方法需要创建自定义规则并重新启动 fapolicyd 服务。

fapolicyd 服务配置位于 /etc/fapolicyd/ 目录中,结构如下。

  • fapolicyd.rules 文件包含了允许拒绝执行规则。
  • fapolicyd.conf文件包含守护进程的配置选项。此文件主要用于性能调优目的。

您可以使用 fapolicyd 完整性检查方法之一:

  • 文件大小检查
  • 比较 SHA-256 哈希
  • 完整性映射架构(IMA)子系统

默认情况下,fapolicyd 不进行完整性检查。根据文件大小进行完整性检查是快速的,但攻击者可以替换文件的内容并保留其字节大小。计算和检查 SHA-256 校验和更安全,但这会影响系统性能。fapolicyd.conf 中的 integrity = ima 选项需要在所有包含可执行文件的文件系统上支持扩展属性(也称为 xattr)。

其它资源

13.2. 部署 fapolicyd

在 RHEL 中部署 fapolicyd 框架:

流程

  1. 安装 fapolicyd 软件包:

    # yum install fapolicyd
  2. 启用并启动 fapolicyd 服务:

    # systemctl enable --now fapolicyd

验证

  1. 验证 fapolicyd 服务是否在正确运行:

    # systemctl status fapolicyd
    ● fapolicyd.service - File Access Policy Daemon
       Loaded: loaded (/usr/lib/systemd/system/fapolicyd.service; enabled; vendor p>
       Active: active (running) since Tue 2019-10-15 18:02:35 CEST; 55s ago
      Process: 8818 ExecStart=/usr/sbin/fapolicyd (code=exited, status=0/SUCCESS)
     Main PID: 8819 (fapolicyd)
        Tasks: 4 (limit: 11500)
       Memory: 78.2M
       CGroup: /system.slice/fapolicyd.service
               └─8819 /usr/sbin/fapolicyd
    
    Oct 15 18:02:35 localhost.localdomain systemd[1]: Starting File Access Policy D>
    Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Initialization of the da>
    Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Reading RPMDB into memory
    Oct 15 18:02:35 localhost.localdomain systemd[1]: Started File Access Policy Da>
    Oct 15 18:02:36 localhost.localdomain fapolicyd[8819]: Creating database
  2. 以没有 root 权限的用户身份登录,检查 fapolicyd 是否 正常工作,例如:

    $ cp /bin/ls /tmp
    $ /tmp/ls
    bash: /tmp/ls: Operation not permitted

13.3. 使用额外的信任源将文件标记为可信

您可以使用这个步骤为 fapolicyd 使用额外的信任源。在 RHEL 8.3 之前,fapolicyd 只信任 RPM 数据库中包含的文件。fapolicyd 框架现在也支持使用 /etc/fapolicyd/fapolicyd.trust 纯文本文件作为信任源。您可以使用文本编辑器直接或通过 fapolicyd CLI 命令修改 fapolicyd.trust

注意

更喜欢使用 fapolicyd.trust 将文件标记为可信,而不是编写自定义 fapolicyd 规则。

先决条件

  • fapolicyd 框架部署在您的系统上。

流程

  1. 将自定义二进制文件复制到所需目录中,例如:

    $ cp /bin/ls /tmp
    $ /tmp/ls
    bash: /tmp/ls: Operation not permitted
  2. 将您的自定义二进制文件标记为 trusted:

    # fapolicyd-cli --file add /tmp/ls

    请注意,上一命令将对应的行添加到 /etc/fapolicyd/fapolicyd.trust

  3. 更新 fapolicyd 数据库:

    # fapolicyd-cli --update
  4. 重启 fapolicyd

    # systemctl restart fapolicyd

验证

  1. 检查您的自定义二进制文件现在是否可以执行,例如:

    $ /tmp/ls
    ls

其它资源

  • fapolicyd.trust(5) man page.

13.4. 为 fapolicyd 添加自定义允许和拒绝规则

fapolicyd 包中的默认规则集不影响系统功能。对于自定义场景,例如将二进制文件和脚本存储在非标准目录中,或者在没有 yumrpm 安装程序的情况下添加应用程序,您必须修改现有规则或添加新规则。以下步骤演示了如何添加新的规则以允许自定义二进制文件。

先决条件

  • fapolicyd 框架部署在您的系统上。

流程

  1. 将自定义二进制文件复制到所需目录中,例如:

    $ cp /bin/ls /tmp
    $ /tmp/ls
    bash: /tmp/ls: Operation not permitted
  2. 停止 fapolicyd 服务:

    # systemctl stop fapolicyd
  3. 使用调试模式来标识对应的规则。因为 fapolicyd --debug 命令的输出详细,且您只能按 Ctrl+C 或终止相应的进程来停止它,因此请将错误输出重定向到文件:

    # fapolicyd --debug 2> fapolicy.output &
    [1] 51341

    或者,您可以在另一个终端中运行 fapolicyd debug 模式。

  4. 重复不允许的命令:

    $ /tmp/ls
    bash: /tmp/ls: Operation not permitted
  5. Ctrl+C 来停止调试模式:

    # fg
    fapolicyd --debug
    ^Cshutting down...
    Inter-thread max queue depth 1
    Allowed accesses: 2
    Denied accesses: 1
    [...]

    或者,终止 fapolicyd debug 模式的进程:

    # kill 51341
  6. 查找拒绝执行应用程序的规则:

    # cat fapolicy.output
    [...]
    rule:9 dec=deny_audit perm=execute auid=1000 pid=51362 exe=/usr/bin/bash : file=/tmp/ls ftype=application/x-executable
    [...]
  7. /etc/fapolicyd/fapolicyd.rules 文件中拒绝执行自定义二进制文件的规则添加一个新的 allow 规则。上一命令的输出表明该规则是本例中的规则编号 9

    allow perm=execute exe=/usr/bin/bash trust=1 : path=/tmp/ls ftype=application/x-executable trust=0

    另外,您可以通过在 / etc/fapolicyd/fapolicyd.rules 文件中添加以下规则来允许执行 / tmp 目录中的所有二进制文件:

    allow perm=execute exe=/usr/bin/bash trust=1 : dir=/tmp/ all trust=0
  8. 要防止自定义二进制文件的内容更改,请使用 SHA-256 校验和定义所需的规则:

    $ sha256sum /tmp/ls
    780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836  ls

    将规则改为以下定义:

    allow perm=execute exe=/usr/bin/bash trust=1 : sha256hash=780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836
  9. 启动 fapolicyd 服务:

    # systemctl start fapolicyd

验证

  1. 检查您的自定义二进制文件现在是否可以执行,例如:

    $ /tmp/ls
    ls

其它资源

  • fapolicyd.trust(5) man page.

13.5. 启用 fapolicyd 完整性检查

默认情况下,fapolicyd 不执行完整性检查。您可以通过比较文件大小或 SHA-256 哈希,配置 fapolicyd 来执行完整性检查。您还可以使用完整性测量架构(IMA)子系统来设置完整性检查。

先决条件

  • fapolicyd 框架部署在您的系统上。

流程

  1. 在您选择的文本编辑器中打开 /etc/fapolicyd/fapolicyd.conf 文件,例如:

    # vi /etc/fapolicyd/fapolicyd.conf
  2. 完整性 选项的值从 none 改为 sha256,保存文件并退出编辑器:

    integrity = sha256
  3. 重启 fapolicyd 服务:

    # systemctl restart fapolicyd

验证

  1. 备份用于验证的文件:

    # cp /bin/more /bin/more.bak
  2. 更改 /bin/more 二进制文件的内容:

    # cat /bin/less > /bin/more
  3. 以普通用户身份使用更改的二进制文件:

    # su example.user
    $ /bin/more /etc/redhat-release
    bash: /bin/more: Operation not permitted
  4. 恢复更改:

    # mv -f /bin/more.bak /bin/more

13.7. 其它资源

第 14 章 防止系统入侵 USB 设备

USB 设备可以通过欺骗软件、恶意软件或 Trojans 加载,这可能会窃取数据或损坏您的系统。作为红帽企业 Linux 管理员,您可以使用 USBGuard 防止此类 USB 攻击。

14.1. usbguard

借助 USBGuard 软件框架,您可以根据内核中的 USB 设备授权功能,使用允许和禁止设备的基本列表来防止系统入侵 USB 设备。

USBGuard 框架提供以下组件:

  • 带有用于动态交互和策略实施的进程间通信(IPC)接口的系统服务组件
  • 与正在运行的 usbguard 系统服务交互的命令行界面
  • 编写 USB 设备授权策略的规则语言
  • 用于与共享库中实施的系统服务组件交互的 C++ API

usbguard系统服务配置文件(/etc/usbguard/usbguard-daemon.conf)包括授权用户和组使用 IPC 接口的选项。

重要

系统服务提供 USBGuard 公共 IPC 接口。在 Red Hat Enterprise Linux 中,默认情况下,此接口的访问权限仅限于 root 用户。

考虑设置 IPCAccessControlFiles 选项(推荐)或 IPCAllowedUsers 和 IPCAllowedGroups 选项,以限制对 IPC 接口的访问。

确保您没有未配置 Access Control List(ACL),因为这会将 IPC 接口公开给所有本地用户,并允许他们操作 USB 设备的授权状态并修改 USBGuard 策略。

14.2. 安装 USBGuard

使用这个步骤安装并启动 USBGuard 框架。

流程

  1. 安装 usbguard 软件包:

    # yum install usbguard
  2. 创建初始规则集:

    # usbguard generate-policy > /etc/usbguard/rules.conf
  3. 启动 usbguard 守护进程并确保它会在引导时自动启动:

    # systemctl enable --now usbguard

验证

  1. 验证 usbguard 服务是否正在运行:

    # systemctl status usbguard
    ● usbguard.service - USBGuard daemon
       Loaded: loaded (/usr/lib/systemd/system/usbguard.service; enabled; vendor preset: disabled)
       Active: active (running) since Thu 2019-11-07 09:44:07 CET; 3min 16s ago
         Docs: man:usbguard-daemon(8)
     Main PID: 6122 (usbguard-daemon)
        Tasks: 3 (limit: 11493)
       Memory: 1.2M
       CGroup: /system.slice/usbguard.service
               └─6122 /usr/sbin/usbguard-daemon -f -s -c /etc/usbguard/usbguard-daemon.conf
    
    Nov 07 09:44:06 localhost.localdomain systemd[1]: Starting USBGuard daemon...
    Nov 07 09:44:07 localhost.localdomain systemd[1]: Started USBGuard daemon.
  2. 列出 USBGuard 识别的 USB 设备

    # usbguard list-devices
    4: allow id 1d6b:0002 serial "0000:02:00.0" name "xHCI Host Controller" hash...

其它资源

  • usbguard(1) and usbguard-daemon.conf(5) man pages.

14.3. 使用 CLI 阻塞和授权 USB 设备

此流程概述了如何使用 usbguard 命令授权和阻止 USB 设备。

先决条件

  • usbguard 服务已安装并运行。

流程

  1. 列出 USBGuard 识别的 USB 设备

    # usbguard list-devices
    1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
    ...
    6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50
  2. 授权设备 6 与系统交互:

    # usbguard allow-device 6
  3. 取消授权并删除设备 6

    # usbguard reject-device 6
  4. 取消授权并保留设备 6

    # usbguard block-device 6
注意

usbguard 使用 并拒绝 术语,其含义如下:

  • block :暂时不要与此设备交互。
  • reject :忽略这个设备,就像它不存在一样。

其它资源

  • usbguard(1) 手册页.
  • 使用 usbguard --help 命令列出内置帮助。

14.4. 永久阻塞和授权 USB 设备

您可以使用 -p 选项永久阻止和授权 USB 设备。这会在当前策略中添加特定于设备的规则。

先决条件

  • usbguard 服务已安装并运行。

流程

  1. 配置 SELinux,以允许 usbguard 守护进程编写规则。

    1. 显示与 usbguard 相关的 semanage 布尔值。

      # semanage boolean -l | grep usbguard
      usbguard_daemon_write_conf     (off  ,  off)  Allow usbguard to daemon write conf
      usbguard_daemon_write_rules    (on   ,   on)  Allow usbguard to daemon write rules
    2. 可选:如果 usbguard_daemon_write_rules 布尔值已关闭,请将其打开。

      # semanage boolean -m --on usbguard_daemon_write_rules
  2. 列出 USBGuard 识别的 USB 设备

    # usbguard list-devices
    1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
    ...
    6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50
  3. 永久授权设备 6 与系统交互:

    # usbguard allow-device 6 -p
  4. 永久取消授权并删除设备 6

    # usbguard reject-device 6 -p
  5. 永久取消授权并保留设备 6

    # usbguard block-device 6 -p
注意

usbguard 使用术语 并拒绝,其含义如下:

  • block :暂时不要与此设备交互。
  • reject :忽略这个设备,就像它不存在一样。

验证

  1. 检查 USBGuard 规则是否包含您所做的更改。

    # usbguard list-rules

其它资源

  • usbguard(1) 手册页.
  • 使用 usbguard --help 命令列出内置帮助。

14.5. 为 USB 设备创建自定义策略

以下流程包含为 USB 设备创建规则集的步骤,它反映了您的情况的要求。

先决条件

  • usbguard 服务已安装并运行。
  • /etc/usbguard/rules.conf 文件包含了由usbguard generate-policy 命令生成的初始规则集。

流程

  1. 创建一个策略来授权当前连接的 USB 设备,并将生成的规则保存到 rules.conf 文件中:

    # usbguard generate-policy --no-hashes > ./rules.conf

    --no-hashes 选项不会为设备生成哈希属性。在配置设置中避免哈希属性,因为它们可能不是永久的。

  2. 使用您选择的文本编辑器编辑 rule .conf 文件,例如:

    # vi ./rules.conf
  3. 根据需要添加、删除或编辑规则。例如,以下规则只允许带有单一大容量存储接口的设备与系统交互:

    allow with-interface equals { 08:*:* }

    有关详细的规则语言描述和更多示例,请参阅 usbguard-rules.conf(5) man page。

  4. 安装更新的策略:

    # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf
  5. 重启 usbguard 守护进程以应用您的更改:

    # systemctl restart usbguard

验证

  1. 检查您的自定义规则是否在活跃策略中,例如:

    # usbguard list-rules
    ...
    4: allow with-interface 08:*:*
    ...

其它资源

  • usbguard-rules.conf(5) man page.

14.6. 为 USB 设备创建结构化自定义策略

您可以在 /etc/usbguard/rules .d/ 目录中的多个.conf 文件中组织自定义 USBGuard 策略。然后 ,usbguard-daemon 按照字母顺序 将主要 rules.conf 文件与 目录中的 . conf 文件合并。

先决条件

  • usbguard 服务已安装并运行。

流程

  1. 创建授权当前连接的 USB 设备并将生成的规则保存到 new .conf 文件的策略,如 policy.conf

    # usbguard generate-policy --no-hashes > ./policy.conf

    --no-hashes 选项不会为设备生成哈希属性。在配置设置中避免哈希属性,因为它们可能不是永久的。

  2. 使用您选择的文本编辑器显示 policy.conf 文件,例如:

    # vi ./policy.conf
    ...
    allow id 04f2:0833 serial "" name "USB Keyboard" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown"
    ...
  3. 将所选行移到单独的 .conf 文件中。

    注意

    文件名开头的两位数字指定守护进程读取配置文件的顺序。

    例如,将键盘的规则复制到 new .conf 文件中。

    # grep "USB Keyboard" ./policy.conf > ./10keyboards.conf
  4. 将新策略安装到 /etc/usbguard/rules.d/ 目录中。

    # install -m 0600 -o root -g root 10keyboards.conf /etc/usbguard/rules.d/10keyboards.conf
  5. 将其余行移到主要 rules.conf 文件中。

    # grep -v "USB Keyboard" ./policy.conf > ./rules.conf
  6. 安装剩余的规则。

    # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf
  7. 重新启动 usbguard 守护进程,以应用您的更改。

    # systemctl restart usbguard

验证

  1. 显示所有活动的 USBGuard 规则。

    # usbguard list-rules
    ...
    15: allow id 04f2:0833 serial "" name "USB Keyboard" hash "kxM/iddRe/WSCocgiuQlVs6Dn0VEza7KiHoDeTz0fyg=" parent-hash "2i6ZBJfTl5BakXF7Gba84/Cp1gslnNc1DM6vWQpie3s=" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown"
    ...
  2. 显示 /etc/usbguard/rules .d/ 目录中 rule .conf 文件的内容以及所有. conf 文件。

    # cat /etc/usbguard/rules.conf /etc/usbguard/rules.d/*.conf
  3. 验证活动规则是否包含来自文件中的所有规则,并且 的顺序正确。

其它资源

  • usbguard-rules.conf(5) man page.

14.7. 授权用户和组使用 USBGuard IPC 接口

使用这个步骤授权特定用户或组使用 USBGuard 公共 IPC 接口。默认情况下,只有 root 用户可以使用此接口。

先决条件

  • usbguard 服务已安装并运行。
  • /etc/usbguard/rules.conf 文件包含了由usbguard generate-policy 命令生成的初始规则集。

流程

  1. 使用您选择的文本编辑器编辑 /etc/usbguard/usbguard-daemon.conf 文件:

    # vi /etc/usbguard/usbguard-daemon.conf
  2. 例如,添加一个规则,允许 wheel 组 中的所有用户使用 IPC 接口,并保存文件:

    IPCAllowGroups=wheel
  3. 您还可以使用 usbguard 命令添加用户或组。例如,以下命令可让 joesec 用户完全访问 DevicesExceptions 部分。此外,joesec 可以列出当前的策略并侦听策略信号。

    # usbguard add-user joesec --devices ALL --policy list,listen --exceptions ALL

    若要删除为 joesec 用户授予的权限,可使用 usbguard remove-user joesec 命令。

  4. 重启 usbguard 守护进程以应用您的更改:

    # systemctl restart usbguard

其它资源

  • usbguard(1) and usbguard-rules.conf(5) man pages.

14.8. 将 USBguard 授权事件记录到 Linux Audit 日志

使用以下步骤将 USBguard 授权事件记录集成到标准的 Linux Audit 日志中。默认情况下,usbguard 守护进程将事件记录到 /var/log/usbguard/usbguard-audit.log 文件。

先决条件

  • usbguard 服务已安装并运行。
  • auditd 服务正在运行。

流程

  1. 使用您选择的文本编辑器编辑 usbguard-daemon.conf 文件:

    # vi /etc/usbguard/usbguard-daemon.conf
  2. AuditBackend 选项从 FileAudit 改为 LinuxAudit

    AuditBackend=LinuxAudit
  3. 重启 usbguard 守护进程以应用配置更改:

    # systemctl restart usbguard

验证

  1. 查询 USB 授权事件 的审计 守护进程日志,例如:

    # ausearch -ts recent -m USER_DEVICE

其它资源

  • usbguard-daemon.conf(5) 手册页.

14.9. 其它资源

  • usbguard(1)、 usbguard-rules.conf(5)usbguard-daemon(8)和 usbguard-daemon.conf(5) man page.
  • USBGuard 主页.