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. 加密软件和认证

Red Hat Enterprise 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)在服务器或工作站上运行,而管理员没有意识到,这可能会给服务器造成不必要的流量,甚至造成进入系统的潜在通途,导致攻击者进入系统。

未应用补丁的服务

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

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

开发人员和系统管理员通常会在服务器应用程序中找到可利用的 bug ,并在 bug 跟踪和安全相关的网站上发布信息,如 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 可能不像网络或服务器那样容易受到攻击,但是因为它们通常包含敏感数据,如信用卡信息,它们仍然是系统攻击者的目标。工作站也可以在用户不知情的情况下被使用,并被攻击者用作协同攻击中的“机器人”机器。因此,了解工作站的漏洞可让用户避免重装操作系统的麻烦,或者更糟糕的是从数据失窃中恢复。

不好的密码

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

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

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

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

1.7. 常见的漏洞和攻击

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

表 1.1. 常见的漏洞

漏洞Description备注

空密码或默认密码

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

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

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

管理员有时会匆忙创建特权用户帐户,并将密码置为空,从而为发现该帐户的恶意用户创建了一个完美的入口点。

默认的共享密钥

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

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

IP 欺骗

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

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

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

窃听

通过窃听两个节点之间的连接,来收集网络上两个活动节点之间传递的数据。

这种类型的攻击主要适用于明文传输协议,如 Telnet、FTP 和 HTTP 传输。

远程攻击者必须能够访问局域网中一个被破坏的系统才能执行此类攻击;通常黑客使用主动攻击(如 IP 欺骗或中间人)来破坏局域网上的系统。

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

服务漏洞

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

基于 HTTP 的服务(如 CGI)容易受到远程命令执行甚至交互式 shell 访问的攻击。即使 HTTP 服务以非特权用户(如"nobody")的身份运行,可以读取的配置文件和网络映射等信息,或者攻击者可以发起拒绝服务攻击,从而耗尽系统资源或使其对其他用户不可用。

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

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

应用程序漏洞

攻击者在桌面和工作站应用程序(如电子邮件客户端)中发现错误,执行任意代码,植入特洛伊木马以备将来入侵,或使系统崩溃。如果被入侵的工作站对网络的其余部分具有管理特权,则可能会被进一步利用。

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

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

拒绝服务(DoS)攻击

攻击者或攻击者组通过向目标主机(服务器、路由器或工作站)发送未经授权的数据包,来协调针对组织的网络或服务器资源的攻击。这将迫使合法用户无法使用该资源。

美国报告的最新 DoS 问题单在 2000 年发生。几个高流量的商业和政府站点被协同的 ping 洪水攻击造成不可用,这些攻击使用了几个被破坏的系统,这些系统的高带宽连接被作为 僵尸,或重定向广播节点。

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

使用 nftables 数据包过滤框架和网络入侵检测系统(如 snort)入口过滤(RFC 2267)的进步有助于管理员跟踪并防止分布式 DoS 攻击。

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

安全性甚至在您开始安装 Red Hat Enterprise 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 或内部网连接就足够了,而互联网连接的风险最大。要遵循最佳安全实践,在从网络安装 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 章 保护服务

在组织中,监视活动的网络服务非常重要,这些服务对对于管理员和 Linux 系统管理员非常重要。Red Hat Enterprise Linux 8 支持许多网络服务器。当某一网络服务在计算机上运行时,守护进程会持续侦听网络端口上的连接。这些守护进程可能会导致任何类型的连接。因此,需要对服务进行安全保护,以防止发生任何错误。本章帮助您保护不同的服务。

3.1. 保护 rpcbind

rpcbind 服务是用于远程过程调用(RPC)服务的动态端口分配守护进程,如网络信息服务(NIS)和网络文件共享(NFS)。由于其身份验证机制较弱,并可为其控制的服务分配大量端口,因此保护 rpcbind 服务非常重要。

您可以通过对服务器添加防火墙规则来保护 rpcbind 服务。您可以限制对所有网络的访问,并使用防火墙规则定义特定的异常。

注意
  • NFSv2NFSv3 服务器需要 rpcbind 服务,在使用 rpcbind 服务时,应确保其安全。
  • NFSv4 不需要 rpcbind 服务来侦听网络。

流程

  • 以下是 firewalld 命令的示例:

    • 限制 TCP 连接,并只接受来自 192.168.0.0/24 主机 111 端口的包:

      # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop'
    • 限制 TCP 连接,并只接受来自本地主机 111 端口的包:

      # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept'
    • 限制 UDP 连接,并只接受来自 192.168.0.0/24 主机 111 端口的包:

      # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'
      注意
      • 要使防火墙设置永久化,请在添加防火墙规则时使用 --permanent 选项。
      • 使用 # firewall-cmd --reload 命令重新加载防火墙以接受新规则。

验证步骤

  • 验证防火墙规则:

    # firewall-cmd --list-rich-rule
    rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop
    rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept
    rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop

其它资源

3.2. 保护 rpc.mountd

rpc.mountd 守护进程实现 NFS 挂载协议的服务器端。NFS 挂载协议用于 NFS 版本 2(RFC 1904)和 NFS 版本 3(RFC 1813)。

您可以通过对服务器添加防火墙规则来保护 rpc.mountd 服务。您可以限制对所有网络的访问,并使用防火墙规则定义特定的异常。

流程

  • 以下是 firewalld 命令的示例:

    • 接受来自 192.168.0.0/24 主机的mountd 连接:

      # firewall-cmd --add-rich-rule 'rule family="ipv4" service name="mountd" source address="192.168.0.0/24" invert="True" drop'
    • 接受来自本地主机的 mountd 连接:

      # firewall-cmd --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'
      注意
      • 要使防火墙设置永久化,请在添加防火墙规则时使用 --permanent 选项。
      • 使用 # firewall-cmd --reload 命令重新加载防火墙以接受新规则。

验证步骤

  • 验证防火墙规则:

    # firewall-cmd --list-rich-rule
    rule family="ipv4" service name="mountd" source address="192.168.0.0/24" invert="True" drop
    rule family="ipv4" source address="127.0.0.1" service name="mountd" accept

3.3. 保护 NFS

以前,Linux 系统管理员无法保护网络文件系统(NFS),因为 NFSv2 和 NFSv3 不安全地传递数据。通过 NFSv4,您可以使用 Kerberos 验证并加密所有文件系统操作。使用 NFSv4 时,如果客户端位于 NAT 或防火墙后面,则可能会关闭委派。相反,NFSv2 和 NFSv3 不使用带有文件锁定和挂载文件操作的 Kerberos 。

可在所有版本中使用 TCP 来发送 NFS 流量。NFS 支持 Kerberos 用户和组身份验证,来作为 RPCSEC_GSS 内核模块的一部分。

NFS 允许远程主机通过网络挂载文件系统,并与这些文件系统进行交互,就像它们被挂载到本地一样。这使系统管理员能够将资源整合到网络上的集中式服务器上。您可以在 /etc/nfsmount.conf 文件中自定义 NFS 挂载选项,该文件还用于设置默认选项。

系统管理员应定期检查 NFS 服务器和 NFS 客户端是否存在任何可能的威胁或攻击,以确保 NFS 的安全。

3.3.1. 保护 NFS 配置

NFS 服务器确定哪个文件系统要导出到哪个主机。所有这些详细信息都添加到 /etc/exports 文件中。在配置文件中添加目录和主机时,您应非常谨慎。编辑此文件时请注意,不要添加额外的空格,因为它可能会导致重大更改。

以下是几个编写 /etc/exports 文件时的示例:

  • 在以下行中,/tmp/nfs/ 目录与 bob.example.com 主机共享,并具有读写权限。
/tmp/nfs/     bob.example.com(rw)
  • 以下行与上一行相同,但对 bob.example.com 主机共享具有只读权限的相同的目录,由于主机名后面有一个空格字符,因此可以对 世界 共享具有读写权限的目录。
/tmp/nfs/     bob.example.com (rw)
注意

要验证系统中共享的内容,请执行 showmount -e <hostname> 命令。

3.3.2. 保护 NFS 服务器的导出选项

NFS 服务器的主配置在 /etc/exports 文件中。以下是允许您安全导出文件系统的 NFS 共享选项列表:

警告

要导出整个文件系统,因为导出文件系统的子目录不安全。攻击者可能会侵入到部分导出的文件系统中未导出的部分。

  • ro - 使用 ro 选项将 NFS 卷导出为只读。
  • rw - 使用 rw 选项允许对 NFS 卷进行读写请求。您应该谨慎使用这个选项,因为允许写权限会增加攻击的风险。
  • root_squash - 使用 root_squash 选项将来自 uid/gid 0 的请求映射到匿名 uid/gid。这不适用于可能同样敏感的任何其他 uidgids,如用户 bin 或组 staff。
  • no_root_squash - 使用 no_root_squash 选项关闭根压缩,不要使用这个选项,而是检查现有的安装。默认情况下,NFS 共享将 root 用户改为 nobody 用户,这是一个非特权用户帐户。这会将所有 root 创建的文件的所有者改为 nobody,这样可以防止上传设置了 setuid 位的程序。如果使用 no_root_squash 选项,则远程 root 用户可以更改共享文件系统上的任何文件,并将感染特洛伊木马的应用程序留给其他用户。
  • secure - 使用 secure 选项将导出限制到保留的端口。默认情况下,服务器仅允许来自保留端口的客户端通信。但是在网络上,任何人很容易成为客户端上的 root 用户,因此,对于服务器来说,假设来自保留端口的通信都具有特权几乎是不安全的。因此,对保留端口的限制具有有限的值;最好根据 Kerberos、防火墙和对特定客户端的导出限制来决定。

另外,在导出 NFS 服务器时请考虑以下最佳实践:

  • 如果必须使用 rw 选项来挂载目录,请确保它们不可全局写入,从而降低可能的风险。
  • 导出主目录存在风险,因为某些应用以纯文本或弱加密格式存储密码。检查和改进应用程序代码有助于降低此类风险。有些用户未对 SSH 密钥设置密码,这再次给主目录带来风险。强制使用密码或使用 Kerberos 可降低该风险。
  • 只将导出限制给需要访问权限的客户端。在 NFS 服务器上使用 showmount -e 命令来检查服务器正在导出什么。不要导出不需要的任何内容。
  • 最好不允许用户登录到服务器。查看 NFS 服务器上的以上设置时,请查看谁和什么可以访问服务器。

3.3.3. 保护 NFS 客户端的挂载选项

您可以将以下选项传给 mount 命令,以提高基于 NFS 的客户端的整体安全:

  • nosuid - 使用 nosuid 选项来禁用 set-user-identifierset-group-identifier 位。这可防止远程用户通过运行 setuid 程序获得更高的特权。使用 nosuid 选项来禁止使用 setuid 选项。
  • noexec - 使用 noexec 选项来禁用客户端上的所有可执行文件。使用此选项来防止用户意外执行放在被共享的文件系统中的文件。
  • nodev - 使用 nodev 选项来防止客户端将设备文件作为硬件设备来处理。
  • resvport - 使用 resvport 选项来限制对"保留端口"的通信。保留或已知的端口保留给特权用户和进程,如 root 用户。设置此选项可让客户端使用特权源端口与服务器进行通信。
  • sec - 在所有 NFS 版本中使用 sec 选项,因为它现在支持使用 Kerberos 身份验证进行挂载。NFSv4 支持对完整性使用 krb5i ,对隐私性使用 krb5p 进行 Kerberos 挂载。当使用 sec=<flavors> 挂载时会使用它们,其中有效的 flavor 为 nonesyskrb5krb5ikrb5p。这些选项需要在 NFS 服务器上进行配置。
重要

krb5-libs 软件包提供的 MIT Kerberos 库不支持新部署中的数据加密标准(DES)算法。由于安全性和某些兼容性原因,在 Kerberos 库中,DES 默认被弃用并禁用。只有在您的环境不支持任何更新和更安全得算法时,才出于兼容性的原因使用 DES。

3.3.4. NFS 服务器的防火墙配置

要保护 NFS 服务器上的防火墙,请仅开放所需的端口。为 NFS 连接指定的端口号不得被任何其他服务使用。

  • Red Hat Enterprise Linux 8 默认支持 NFSv4。防火墙必须为 NFSv4 流量打开 TCP 端口 2049
  • 在 RHEL 8 中使用 NFSv3 时,您需要打开四个额外的端口,如下所示:

    • rpcbind 服务动态分配 NFS 端口,这可能会在创建防火墙规则时导致问题。要简化此过程,请使用 /etc/nfs.conf 文件来指定要使用的端口:

      • mountd (rpc.mountd)的 TCP 和 UDP 端口- 在 [mountd] 部分中设置 port=<value>
      • statd(rpc.statd) 的 TCP 和 UDP 端口 - 在 [statd] 部分中设置 port=<value>
    • 在 Red Hat Enterprise Linux 8 中,对 /etc/nfs.conf 文件中为 NFS 锁定管理器(nlockmgr)设置 TCP 和 UDP 端口:

      • nlockmgr (rpc.statd)的 TCP 端口 - 在 [lockd] 部分中设置 port=value 。它的效果与 /etc/modprobe.d/lockd.conf 文件中的 nlm_tcpport 选项相同。
      • nlockmgr (rpc.statd)的 UDP 端口 - 在 [lockd] 部分中设置 udp-port=value 。它的效果与 /etc/modprobe.d/lockd.conf 文件中的 nlm_udpport 选项相同。
注意

要验证 NFS 服务器上正在使用哪些端口和 RPC 程序,请使用 -p 参数执行 rpcinfo 命令。

其它资源

3.4. 保护 FTP

文件传输协议(FTP)通过网络传输文件。FTP 是一种不安全的协议,因为与服务器进行的所有事务(包括用户身份验证)均未加密,因此应仔细配置。

Red Hat Enterprise Linux 8 提供两个 FTP 服务器:

  • 红帽内容加速器(tux)- 具有 FTP 功能的内核空间 Web 服务器。
  • 非常安全的 FTP 守护进程(vsftpd)- FTP 服务的一种独立的、面向安全的实现。

以下安全指南是用于设置 vsftpd FTP 服务:

保护标语

FTP 服务向所有用户显示问候标语。默认情况下,此标语包含版本信息,其有助于攻击者识别系统中的漏洞。默认标语类似如下:

$ ftp localhost
Trying ::1...
Connected to localhost (::1).
220 (vsFTPd 3.0.3)
  • 要更改 vsftpd FTP 服务的问候标语,请在 /etc/vsftpd/vsftpd.conf 文件中添加以下指令:

    ftpd_banner=<insert_greeting_here>

    修改后的标语类似如下:

    $ ftp localhost
    Trying ::1...
    Connected to localhost (::1).
    Welcome to the FTP service.
  • 要制作多行标语,最好使用标语文件。要简化对多个标语的管理,请将所有标语放在 /etc/banners/ 目录中。本例中 FTP 连接的标语文件为 /etc/banners/ftp.msg

    以下是此类文件的一个示例:

    ######### Hello, all activity on ftp.example.com is logged. #########

    要对 vsftpd FTP 服务引用 /etc/banners/ftp.msg 问候标语文件,请在 /etc/vsftpd/vsftpd.conf 文件中添加文件:

    banner_file=/etc/banners/ftp.msg

防止匿名访问和上传

  • 安装 vsftpd 软件包时,会创建 /var/ftp/ 目录。默认情况下,此软件包为对目录具有只读权限的匿名用户建立目录树。由于匿名用户可以访问数据,因此请注意敏感数据的存储位置。
  • 要允许匿名用户在 FTP 服务器上上传文件,请执行以下步骤:

    • /var/ftp/pub/ 目录中创建一个只有写权限的目录:

      # mkdir /var/ftp/pub/upload
    • 为安全起见更改目录的权限:

      # chmod 730 /var/ftp/pub/upload
      # ls -ld /var/ftp/pub/upload
      drwx-wx---. 2 root ftp 4096 Nov 14 22:57 /var/ftp/pub/upload
    • /etc/vsftpd/vsftpd.conf 文件中添加以下行:

      anon_upload_enable=YES
      anonymous_enable=YES

      启用 SELinux 并强制实现时,您还应检查 SELinux 布尔属性 allow_ftpd_anon_writeallow_ftpd_full_access

  • 允许匿名用户在目录中进行读写的管理员通常会发现其服务器成为盗窃软件的存储库。

保护用户帐户

  • FTP 通过不安全的网络传输用户名和密码来进行身份验证,最好拒绝系统用户从其用户帐户访问服务器。

    要在 vsftpd 服务器中禁用所有用户帐户,请将以下指令添加到 /etc/vsftpd/vsftpd.conf 中:

    local_enable=NO
  • 要禁用特定帐户或特定帐户组(如 root 用户和具有 sudo 特权的组)的 FTP 访问,您可以使用 vsftpd 服务的 /etc/pam.d/vsftpd PAM 配置文件。
  • 可以在 vsftpd 服务中禁用用户帐户。为此,请将用户名添加到 /etc/vsftpd/ftpusers 文件中。

3.5. 安全 HTTP 服务器

3.5.1. 安全 Apache HTTP 服务器

Apache HTTP 服务器是红帽企业 Linux 中最稳定和安全的服务之一。有许多选项和技术可用于保护 Apache HTTP 服务器。下面的部分简要说明了运行 Apache HTTP 服务器时的良好做法。

始终验证系统上运行的任何脚本在投入生产之前可以正常工作。此外,确保只有 root 用户对包含脚本或 CGI 的任何目录具有写入权限。要验证,以 root 用户身份输入以下命令:

# chown root directory-name
# chmod 755 directory-name

/etc/httpd/conf/httpd.conf 文件中,您可以配置以下选项:

FollowSymLinks
此指令默认为启用,因此在创建符号链接时应小心。
索引
此指令默认为启用。禁用此指令,以防止访问者浏览服务器上的文件。
UserDir
此指令默认为禁用,因为它可以确认系统上是否存在用户帐户。要激活 /root/ 之外的所有用户目录浏览,请使用 UserDir enabledUserDir disabled root 指令。若要将用户添加到已禁用帐户的列表,请在 UserDir disabled 行上添加空格分隔的用户列表。
ServerTokens

此指令控制发送回客户端的服务器响应标头字段。它包括以下参数可自定义的各种信息:

ServerTokens Full

提供所有可用的信息,如 Web 服务器版本号、服务器操作系统详情、安装的 Apache 模块,例如:

Apache/2.4.37 (Red Hat Enterprise Linux) MyMod/1.2
ServerTokens Full-Release

通过发行版本提供所有可用信息,例如:

Apache/2.4.37 (Red Hat Enterprise Linux) (Release 41.module+el8.5.0+11772+c8e0c271)
ServerTokens ProdServerTokens 产品

提供 Web 服务器名称,例如:

Apache
ServerTokens Major

提供 Web 服务器主发行版本,例如:

Apache/2
ServerTokens Minor

提供 Web 服务器次要发行版本,例如:

Apache/2.4
ServerTokens MinServerTokens Minimal

提供 web 服务器最小发行版本,例如:

Apache/2.4.37
ServerTokens OS

提供 Web 服务器发行版本和操作系统,例如:

Apache/2.4.37 (Red Hat Enterprise Linux)

使用 ServerTokens Prod 选项防止攻击者获取有关您系统的任何宝贵信息。

重要

不要删除 IncludesNoExec 指令。默认情况下,Server-Side Includes(SSI)模块无法执行命令。除非绝对必要,否则请不要更改此设置,因为它可能会使攻击者在系统上输入命令。

删除 httpd 模块

在某些情况下,删除某些 httpd 模块来限制 HTTP 服务器的功能会很有帮助。为此,请编辑 /etc/httpd/conf.modules.d/ 或 /etc/ httpd/conf.d/ 目录中的配置文件。例如,删除代理模块:

echo '# All proxy modules disabled' > /etc/httpd/conf.modules.d/00-proxy.conf

3.5.2. 安全 NGINX 服务器

NGINX 是高性能 HTTP 和代理服务器。您可以在 NGINX 配置文件的 server 部分中执行以下配置更改,以强化 NGINX 配置。

禁用版本字符串

禁用 server_tokens 配置选项,以停止显示其他详细信息,如服务器版本号。此配置在 NGINX 提供的所有请求中仅显示服务器名称,例如:

$ curl -sI http://localhost | grep Server
Server: nginx

包括其他与安全相关的标头

NGINX 服务的每个请求都可以包括额外的 HTTP 标头来缓解某些已知的 Web 应用程序漏洞:

添加_header X-Frame-Options SAMEORIGIN;
此选项拒绝域外的任何页面框,以构建由 NGINX 提供的任何内容,从而减少了点击攻击。
add_header X-Content-Type-Options nosniff;
这个选项可防止在某些较旧的浏览器中使用 MIME 类型嗅探功能。
add_header X-XS-Protection "1; mode=block";
此选项启用跨站点脚本(XSS)过滤,可防止浏览器呈现 NGINX 响应中包含的潜在恶意内容。

限制 HTTP 方法

您可以限制面向公众的服务,并限制他们从事的工作和接受访客的行为。例如,以下代码片段将限制对除 GETHEAD 以外的所有方法的访问:

limit_except GET {
    allow 192.168.1.0/32;
    deny  all;
}

禁用 HTTP 方法

如果启用,一些 HTTP 方法可能会允许攻击者在 Web 服务器上执行专为开发人员测试 Web 应用的操作。例如,了解 TRACE 方法允许跨站点跟踪(XST)。NGINX 服务器可以通过仅允许特定方法禁止这些错误的 HTTP 方法以及任意方法。例如:

# Allow GET, PUT, POST; return "405 Method Not Allowed" for all others.
if ( $request_method !~ ^(GET|PUT|POST)$ ) {
    return 405;
}

配置 SSL

要保护 NGINX Web 服务器提供的数据,请考虑仅通过 HTTPS 提供。您可以生成安全配置配置文件,以使用 Mozilla SSL 配置生成器在 NGINX 服务器中启用 SSL。生成的配置可确保禁用已知漏洞协议(如 SSLv2 或 SSLv3)、密码和哈希算法(如 3DES 或 MD5)。您还可以使用 SSL 服务器测试来验证您的配置是否满足现代安全要求。

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

要启用联邦信息处理标准(FIPS)140-2 要求的加密模块自我检查,您必须以 FIPS 模式运行 RHEL 8。

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

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

为避免加密密钥材料再生和重新评估与转换已部署系统相关的最终系统的合规性,红帽建议以 FIPS 模式开始安装。

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

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

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

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

4.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.

4.3. 其它资源

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

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

5.1. 系统范围的加密策略

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

RHEL 8 包含以下预定义的策略:

DEFAULT

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

LEGACY

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

FUTURE

这是一种保守的安全级别,被认为可以抵御任何近期的攻击。这个级别不允许在签名算法中使用 SHA-1。它允许 TLS 1.2 和 1.3 协议,以及 IKEv2 和 SSH2 协议。如果 RSA 密钥和 Diffie-Hellman 参数至少是 3072 位,则可以接受它们。

FIPS

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

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

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

重要

因为客户门户网站 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 开始)

在加密策略级别中启用的密码套件和协议

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

 LEGACYDEFAULTFIPSFUTURE

IKEv1

3DES

RC4

DH

最少 1024 位

最少 2048 位

最少 2048 位

最少 3072 位

RSA

最少 1024 位

最少 2048 位

最少 2048 位

最少 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。要禁用 AES-256-CBC,请应用自定义子策略。

其它资源

  • update-crypto-policies(8) 手册页

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

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

警告

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

流程

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

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

其它资源

  • 有关可用的加密策略级别列表,请参阅 update-crypto-policies(8) 手册页。
  • 有关定义自定义加密策略的信息,请参阅 update-crypto-policies(8) 手册页中的 自定义策略 部分,以及 crypto-policies(7) 手册页中的 加密策略定义格式 部分。

5.3. 将系统切换到 FIPS 模式

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

重要

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

流程

  1. 将系统切换到 FIPS 模式:

    # fips-mode-setup --enable
    Kernel initramdisks are being regenerated. This might take some time.
    Setting system policy to FIPS
    Note: System-wide crypto policies are applied on application start-up.
    It is recommended to restart the system for the change of policies
    to fully take place.
    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.

其它资源

5.4. 在容器中启用 FIPS 模式

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

注意

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

5.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

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

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

先决条件

流程

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

    $ update-crypto-policies --set FIPS

RHEL 8.2 引入了一种将容器切换到 FIPS 模式的替代方法。它只需要在容器中使用以下命令:

+

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

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

5.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 验证的模块。

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

Application详情

FreeRADIUS

RADIUS 协议使用 MD5

ghostscript

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

ipxe

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

libica

通过 CPACF 指令的各种算法(如 RSA 和 ECDH )的软件回退

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]

AES、DES、RC4

valgrind

AES, hashes[b]

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

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

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

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

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

wget

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

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

如需更多信息,请参阅 wget(1) 手册页中的 HTTPS(SSL/TLS)选项部分。

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
  • 对于整个系统,使用小于 50 的两位数字前缀指定 /etc/ssh/ssh_config.d/ 目录中的置入配置文件中加密策略,因此按字典顺序,它在 50-redhat.conf 文件之前,并带有 .conf 后缀,如 49-crypto-policy-override.conf

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

Libreswan

有关详细信息,请参阅 安全网络 文档中的 配置不使用系统范围加密策略的 IPsec 连接

其它资源

  • update-crypto-policies(8) 手册页

5.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
    min_rsa_size = 3072
    hash = SHA2-384 SHA2-512 SHA3-384 SHA3-512
    cipher@TLS = -CHACHA20-POLY1305
    group@SSH = FFDHE-1024+
    # vi NO-AES128.pmod
    cipher = -AES-128-*
  4. 将更改保存到模块文件中。
  5. 将您的策略调整应用到 DEFAULT 系统范围加密策略级别:

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

    # reboot

其它资源

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

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

重要

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

注意

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

流程

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

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

    # reboot

其它资源

5.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

其它资源

第 6 章 设置跨系统的自定义加密策略

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

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

在加密策略系统角色 playbook 中,您可以根据您的偏好和限制为加密策略配置文件定义参数。

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

加密策略系统角色选择的变量

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

加密策略系统角色设置的事实

crypto_policies_active
列出当前选择的策略。
crypto_policies_available_policies
列出系统上所有可用的策略。
crypto_policies_available_subpolicies
列出系统上所有可用的子策略。

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

您可以使用加密策略系统角色从单个控制节点配置大量的受管节点。

先决条件

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

    在控制节点上:

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

流程

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

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

    您可以将 FUTURE 值替换为您喜欢的加密策略,例如:DEFAULTLEGACYFIPS:OSPP

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

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

  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: rhel-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": 变量显示受管节点上的活动策略。

6.3. 其它资源

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

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

7.1. 通过 PKCS #11 的加密硬件支持

PKCS #11(公钥加密标准)定义了一个应用程序编程接口(API)来保存加密信息并执行加密功能的加密设备。这些设备被称为令牌,它们可以以硬件或软件形式来实现。

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

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

RHEL 默认为智能卡提供 OpenSC PKCS #11 驱动程序。但是,硬件令牌和 HSM 可以有自己的 PKCS #11 模块,这些模块在系统中没有对应项。您可以使用 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

7.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] $

其它资源

7.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) 手册页。

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

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

对于 HTTPS 协议形式的安全通信,Apache HTTP 服务器(httpd)使用 OpenSSL 库。OpenSSL 本身不支持 PKCS #11 。要使用 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 中有详细介绍。

7.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: 前缀。这是因为其它 pkcs11 前缀引用引擎名称。

第 8 章 使用共享的系统证书

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

8.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/
    • /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 架构中,根证书是从中派生信任链的信任锚。要启用链验证,信任方必须首先能够访问信任锚。

8.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 会缓存文件,您可能需要清除浏览器的缓存或重新启动浏览器来加载当前的系统证书配置。

8.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 命令:

    $ 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
    ...
  • 要将信任锚存储到系统范围的信任存储中,请使用 trust anchor 子命令,并指定证书的路径。将 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
    ...

8.4. 其它资源

  • update-ca-trust(8)trust(1) 手册页

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

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

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

9.1. RHEL 中的配置合规工具

Red Hat Enterprise 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 标准的一部分。

要在多个系统上远程执行自动合规审计,您可以使用 Red Hat Satellite 的 OpenSCAP 解决方案。

9.2. 漏洞扫描

9.2.1. 红帽安全咨询 OVAL 源

Red Hat Enterprise 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)名称单独列出,并在我们的公共 bug 数据库中有一个指向其条目的链接。

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

9.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

验证

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

    $ firefox vulnerability.html &

其它资源

9.2.3. 扫描远程系统的漏洞

您还可以使用通过 SSH 协议的 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. 扫描 SSH 在端口 22 上运行、用户名为 joesec、主机名为 machine1 的远程系统上的漏洞,并将结果保存到 remote-vulnerability.html 文件中:

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

其它资源

9.3. 配置合规性扫描

9.3.1. RHEL 中的配置合规性

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

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

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

重要

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

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

合规性扫描资源的结构

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 自定义安全配置文件

9.3.2. OpenSCAP 扫描的可能结果

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

表 9.1. OpenSCAP 扫描的可能结果

结果介绍

Pass

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

Fail

扫描发现与此规则有冲突。

Not checked

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

Not applicable

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

Not selected

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

Error

扫描遇到了错误。要获得更多信息,您可以输入带有 --verbose DEVEL 选项的 oscap 命令。考虑打开 bug 报告

Unknown

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

9.3.3. 查看配置文件是否符合配置合规

在决定使用配置文件进行扫描或修复前,您可以使用 oscap 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. 使用 oscap 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 文件中选择一个配置文件,并显示所选配置文件的额外详情。为此,可使用带有 --profile 选项的 oscap info ,后跟上一命令输出中显示的 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

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

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

先决条件

  • openscap-scannerscap-security-guide 软件包已安装
  • 您知道系统应遵守的基准中的配置文件的 ID。要查找 ID,请参阅 查看配置合规性配置文件

流程

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

    $ sudo oscap xccdf eval --report report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
  2. 可选:扫描 SSH 在端口 22 上运行、用户名为 joesec、主机名为 machine1 的远程系统,并将结果保存到 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

其它资源

9.4. 修复系统,使其与特定基准一致

使用此流程修复 RHEL 系统,使其与特定基准一致。这个示例使用了健康保险可移植性和责任法案(HIPAA)配置文件。

警告

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

先决条件

  • scap-security-guide 软件包已安装在您的 RHEL 系统上。

流程

  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) 手册页

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

使用 SCAP 安全指南项目中的 Ansible playbook 文件,使用这个过程来用特定的基准修复您的系统。这个示例使用了健康保险可移植性和责任法案(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

其它资源

9.6. 创建修复 Ansible playbook,使系统与特定的基准一致

您可以创建一个 Ansible playbook,其只包含使您的系统与特定基准保持一致所需的修正。这个示例使用了健康保险可移植性和责任法案(HIPAA)配置文件。通过这个过程,您可以创建一个较小的 playbook ,其不包括已经满足的需求。按照以下步骤,您不需要以任何方式修改您的系统,您只需为后续应用程序准备一个文件。

先决条件

  • scap-security-guide 软件包已安装在您的 RHEL 系统上。

流程

  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 --profile hipaa --output hipaa-remediations.yml hipaa-results.xml
  3. hipaa-remediations.yml 文件包含对步骤 1 中扫描执行过程中失败的规则的 Ansible 修复。检查生成的文件后,您可以使用 ansible-playbook hipaa-remediations.yml 命令应用该文件。

验证

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

其它资源

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

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

先决条件

  • scap-security-guide 软件包已安装在您的 RHEL 系统上。

流程

  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 命令应用该文件。

验证

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

其它资源

  • scap-security-guide(8)oscap(8)bash(1) 手册页

9.8. 使用 SCAP Workbench 用自定义配置文件扫描系统

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

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

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

先决条件

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

流程

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

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

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

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

    警告

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

  4. 单击Scan按钮,使用所选配置文件扫描您的系统。

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

9.8.2. 使用 SCAP Workbench 自定义安全配置文件

您可以通过更改某些规则中的参数(如最小密码长度)、删除以不同方式涵盖的规则,并选择额外的规则来自定义安全配置文件,以实现内部策略。您不能通过自定义配置文件来定义新规则。

以下流程演示了如何使用 SCAP Workbench 来自定义(定制)配置文件。您还可以保存定制的配置文件,以便在 oscap 命令行工具中使用。。

先决条件

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

流程

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

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

    选择新配置文件的 ID
  3. 使用将规则组织成逻辑组的树结构或 Search 字段查找要修改的规则。
  4. 使用树结构中的复选框来包含或排除规则,或者在适用情况下修改规则中的值。

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

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

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

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

注意

因为 SCAP Workbench 不支持对定制配置文件的基于结果的补救,所以请使用 oscap 命令行工具导出的补救。

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

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

9.9.1. 配置文件与 Server with GUI 不兼容

作为 SCAP 安全指南 的一部分提供的某些安全配置文件与 Server with GUI 基本环境中包含的扩展软件包集合不兼容。因此,在安装与以下配置文件兼容的系统时,不要选择 Server with GUI

表 9.2. 配置文件与 Server with GUI 不兼容

配置文件名称配置文件 ID原因备注

CIS Red Hat Enterprise Linux 8 基准第 2 级 - 服务器

xccdf_org.ssgproject.content_profile_cis

软件包 xorg-x11-server-Xorgxorg-x11-server-commonxorg-x11-server-utilsxorg-x11-server-XwaylandServer with GUI 软件包集合的一部分,但策略需要删除它们。

 

CIS Red Hat Enterprise Linux 8 基准第 1 级 - 服务器

xccdf_org.ssgproject.content_profile_cis_server_l1

软件包 xorg-x11-server-Xorgxorg-x11-server-commonxorg-x11-server-utilsxorg-x11-server-XwaylandServer with GUI 软件包集合的一部分,但策略需要删除它们。

 

非联邦信息系统和组织中的非保密信息(NIST 800-171)

xccdf_org.ssgproject.content_profile_cui

nfs-utils 软件包是 Server with GUI 软件包集合的一部分,但策略需要删除该软件包。

 

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

xccdf_org.ssgproject.content_profile_ospp

nfs-utils 软件包是 Server with GUI 软件包集合的一部分,但策略需要删除该软件包。

BZ#1787156

Red Hat Enterprise Linux 8 的 DISA STIG

xccdf_org.ssgproject.content_profile_stig

软件包 xorg-x11-server-Xorgxorg-x11-server-commonxorg-x11-server-utilsxorg-x11-server-XwaylandServer with GUI 软件包集合的一部分,但策略需要删除它们。

要将 RHEL 系统安装为与 RHEL 8.4 及更高版本中的 DISA STIG 一致的 Server with GUI,您可以使用 DISA STIG with GUI 配置文件。BZ#1648162

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

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

警告

作为 SCAP 安全指南 的一部分提供的某些安全配置文件与 Server with GUI 基本环境中包含的扩展软件包集合不兼容。如需了解更多详细信息,请参阅 与 GUI 服务器不兼容的配置文件

先决条件

  • 您已引导到 图形化 安装程序。请注意,OSCAP Anaconda Add-on 不支持交互式文本安装。
  • 您已访问 安装概述 窗口。

流程

  1. 安装概述 窗口中点击 软件选择。此时会打开 软件选择窗口。
  2. Base Environment 窗格中选择 服务器 环境。您只能选择一个基本环境。
  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 的系统。

验证

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

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

其它资源

9.9.3. 使用 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

其它资源

9.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 是第一个参数。

验证

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

    $ firefox vulnerability.html &

其它资源

  • 如需更多信息,请参阅 oscap-podman(8)oscap(8) 手册页。

9.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 基准的安全合规性,请用您容器镜像的 ID 替换 096cae65a207,用 ospppci-dss 替换 hipaa 。请注意,oscap-podman 命令需要 root 权限。

验证

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

    $ firefox report.html &
注意

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

其它资源

9.12. RHEL 8 中支持的 SCAP 安全指南配置文件

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

在下表中,您可以找到每个 RHEL 次要版本中提供的配置文件,以及配置文件所对应的策略版本。

表 9.3. RHEL 8.5 中支持 SCAP 安全指南配置文件

配置文件名称配置文件 ID策略版本

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

xccdf_org.ssgproject.content_profile_anssi_bp28_enhanced

1.2

法国信息系统安全部(ANSSI)BP-028 高级别

xccdf_org.ssgproject.content_profile_anssi_bp28_high

1.2

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

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 基准第 2 级 - 服务器

xccdf_org.ssgproject.content_profile_cis

1.0.0

CIS Red Hat Enterprise Linux 8 基准第 1 级 - 服务器

xccdf_org.ssgproject.content_profile_cis_server_l1

1.0.0

CIS Red Hat Enterprise Linux 8 基准第 1 级 - 工作站

xccdf_org.ssgproject.content_profile_cis_workstation_l1

1.0.0

CIS Red Hat Enterprise Linux 8 基准第 2 级 - 工作站

xccdf_org.ssgproject.content_profile_cis_workstation_l2

1.0.0

非联邦信息系统和组织中的非保密信息(NIST 800-171)

xccdf_org.ssgproject.content_profile_cui

r1

澳大利亚网络安全中心(ACSC)要点 8

xccdf_org.ssgproject.content_profile_e8

未版本化

健康保险可移植性和责任法案(HIPAA)

xccdf_org.ssgproject.content_profile_hipaa

未版本化

澳大利亚网络安全中心(ACSC)ISM 官方

xccdf_org.ssgproject.content_profile_ism_o

未版本化

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

xccdf_org.ssgproject.content_profile_ospp

4.2.1

Red Hat Enterprise Linux 8 的 PCI-DSS v3.2.1 控制基准

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

针对 Red Hat Enterprise Linux 8 的国防信息系统局安全技术实施指南(DISA STIG)

xccdf_org.ssgproject.content_profile_stig

V1R3

针对带 GUI 的 Red Hat Enterprise Linux 8 的国防部信息系统局安全技术实施指南(DISA STIG)

xccdf_org.ssgproject.content_profile_stig_gui

V1R3

表 9.4. RHEL 8.4 中支持的 SCAP 安全指南配置文件

配置文件名称配置文件 ID策略版本

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

xccdf_org.ssgproject.content_profile_anssi_bp28_enhanced

1.2

法国信息系统安全部(ANSSI)BP-028 高级别

xccdf_org.ssgproject.content_profile_anssi_bp28_high

RHEL 8.4.4 和更高版本:1.2

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

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 基准第 2 级 - 服务器

xccdf_org.ssgproject.content_profile_cis

RHEL 8.4.3 和低版本:1.0.0
RHEL 8.4.4 和更高版本:1.0.1

CIS Red Hat Enterprise Linux 8 基准第 1 级 - 服务器

xccdf_org.ssgproject.content_profile_cis_server_l1

RHEL 8.4.4 和更高版本:1.0.1

CIS Red Hat Enterprise Linux 8 基准第 1 级 - 工作站

xccdf_org.ssgproject.content_profile_cis_workstation_l1

RHEL 8.4.4 和更高版本:1.0.1

CIS Red Hat Enterprise Linux 8 基准第 2 级 - 工作站

xccdf_org.ssgproject.content_profile_cis_workstation_l2

RHEL 8.4.4 和更高版本:1.0.1

非联邦信息系统和组织中的非保密信息(NIST 800-171)

xccdf_org.ssgproject.content_profile_cui

r1

澳大利亚网络安全中心(ACSC)要点 8

xccdf_org.ssgproject.content_profile_e8

未版本化

澳大利亚网络安全中心(ACSC)ISM 官方

xccdf_org.ssgproject.content_profile_ism_o

RHEL 8.4.4 和更高版本:未进行版本控制

健康保险可移植性和责任法案(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 控制基准

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

针对 Red Hat Enterprise Linux 8 的国防信息系统局安全技术实施指南(DISA STIG)

xccdf_org.ssgproject.content_profile_stig

RHEL 8.4.3 和低版本:V1R1
RHEL 8.4.4 和更高版本:V1R3

针对带 GUI 的 Red Hat Enterprise Linux 8 的国防部信息系统局安全技术实施指南(DISA STIG)

xccdf_org.ssgproject.content_profile_stig_gui

RHEL 8.4.4 和更高版本:V1R3

表 9.5. 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)要点 8

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 控制基准

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

[草案] 针对 Red Hat Enterprise Linux 8 的国防信息系统局安全技术实施指南(DISA STIG)

xccdf_org.ssgproject.content_profile_stig

草案

表 9.6. RHEL 8.2 中支持的 SCAP 安全指南配置文件

配置文件名称配置文件 ID策略版本

澳大利亚网络安全中心(ACSC)要点 8

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 控制基准

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

[草案] 针对 Red Hat Enterprise Linux 8 的 DISA STIG

xccdf_org.ssgproject.content_profile_stig

草案

表 9.7. RHEL 8.1 中支持的 SCAP 安全指南配置文件

配置文件名称配置文件 ID策略版本

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

xccdf_org.ssgproject.content_profile_ospp

4.2.1

Red Hat Enterprise Linux 8 的 PCI-DSS v3.2.1 控制基准

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

表 9.8. RHEL 8.0 中支持的 SCAP 安全指南配置文件

配置文件名称配置文件 ID策略版本

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

xccdf_org.ssgproject.content_profile_ospp

草案

Red Hat Enterprise Linux 8 的 PCI-DSS v3.2.1 控制基准

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

第 10 章 使用 AIDE 检查完整性

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

10.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 二进制文件存储在安全的位置,如只读介质。

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

先决条件

  • AIDE 已正确安装,其数据库已初始化。请参阅 安装 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 执行 AIDE,请在 /etc/crontab 文件中添加以下行:

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

10.3. 更新 AIDE 数据库

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

先决条件

  • AIDE 已正确安装,其数据库已初始化。请参阅 安装 AIDE

流程

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

    # aide --update

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

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

10.4. 文件完整性工具:AIDE 和 IMA

Red Hat Enterprise Linux 提供多个用于检查和维护系统上文件和目录完整性的工具。下表可帮助您决定哪个工具更适合您的场景。

表 10.1. AIDE 和 IMA 之间的比较

问题高级入侵检测环境(AIDE)完整性测量架构 (IMA)

什么

AIDE 是一个在系统上创建文件和目录数据库的工具。此数据库用于检查文件完整性及检测入侵检测。

IMA 通过检查与之前存储的扩展属性相比的文件度量(哈希值)来检查文件是否被修改了。

如何

AIDE 使用规则来比较文件和目录的完整性状态。

IMA 使用文件哈希值来检测入侵。

为什么

检测 - AIDE 通过验证规则来检测文件是否被修改。

检测和防止 - IMA 通过替换文件的扩展属性来检测和防止攻击。

使用

当文件或目录被修改了,AIDE 会检测到威胁。

当有人试图更改整个文件时,IMA 会检测到威胁。

扩展

AIDE 检查本地系统上文件和目录的完整性。

IMA 确保本地和远程系统的安全性。

第 11 章 使用内核完整性子系统提高安全性

您可以使用内核完整性(kernel integrity)子系统组件来提高系统保护。以下小节介绍了相关组件,并提供了有关其配置的指导。

11.1. 内核完整性子系统

完整性子系统是内核的一部分,负责维护整个系统的数据完整性。此子系统有助于使特定系统的状态与构建时相同,从而防止用户对特定系统文件进行不必要的修改。

内核完整性子系统由两个主要组件组成:

完整性测量架构 (IMA)
  • 在文件被执行或打开时,会测量文件的内容。用户可以通过应用自定义策略来更改此行为。
  • 将测量的值放置在内核的内存空间内,从而防止系统用户进行任何修改。
  • 允许本地和远程用户验证测量值。
扩展验证模块 (EVM)
  • 通过加密其对应的值,保护与系统安全性(如 IMA 测量和 SELinux 属性)相关的文件的扩展属性(也称为 xattr)。

IMA 和 EVM 还包含大量额外功能扩展。例如:

IMA-Appraisal
  • 根据以前存储在内核内存中的测量文件中的值提供当前文件内容的本地验证。此扩展禁止通过特定文件执行任何操作,以防当前和上一个测量结果不匹配。
EVM 数字签名
  • 允许通过存储在内核密钥环中的加密密钥使用数字签名。
注意

功能扩展相互补充,但您可以独立配置和使用它们。

内核完整性子系统可以利用受信任的平台模块 (TPM) 来更加强化系统安全性。TPM 是受信任的计算组 (TCG) 中有关重要加密功能的规范。TPMS 通常作为专用硬件构建,附加到平台的主板,并通过为硬件芯片受保护且受篡改区域提供加密功能来防止基于软件的攻击。其中一些 TPM 特性包括:

  • 随机数生成器
  • 用于加密密钥的生成器和安全存储
  • 哈希生成器
  • 远程测试

11.2. 完整性测量架构

完整性测量架构 (IMA) 是内核完整性子系统的一个组件。IMA 旨在维护本地文件的内容。具体来说,IMA 在文件访问前测量、存储和应用文件哈希,这可以防止读取和执行不可靠的数据。因此,IMA 增强了系统的安全性。

11.3. 扩展的验证模块

扩展验证模块 (EVM) 是内核完整性子系统的一个组件,可监控文件的扩展属性 (xattr) 中的更改。许多面向安全的技术,包括完整性测量架构 (IMA),将敏感文件信息(如内容散列)存储在扩展属性中。EVM 从这些扩展属性和特殊密钥创建另一个哈希值,该密钥在引导时加载。每次使用扩展属性时,生成的哈希都会被验证。例如,当 IMA 评估文件时。

RHEL 8 接受 evm-key 密钥环下的特殊加密密钥。密钥由内核密钥环中拥有的 master key 创建。

11.4. 可信和加密的密钥

下面的部分介绍了可信和加密的密钥,作为增强系统安全性的重要部分。

可信的加密的密钥是利用内核密钥环服务的内核生成的可变长度对称密钥。这种类型的密钥从未以未加密的形式显示在用户空间中,这意味着可以验证其完整性,这意味着扩展验证模块 (EVM) 可以使用它们来验证并确认运行中系统的完整性。用户级别程序只能访问加密的 Blob 格式的密钥。

受信任的密钥需要硬件组件:受信任的平台模块 (TPM) 芯片,它用于创建和加密密钥。TPM 使用名为存储根密钥 (SRK) 的 2048 位 RSA 密钥密封密钥。

注意

要使用 TPM 1.2 规范,请通过机器固件中的设置或使用 tpm-tools 软件包中的 tpm_setactive 命令启用并激活它。此外,还需要安装 TrouSers 软件堆栈,并且需要运行 tcsd 守护进程才能与 TPM(专用硬件)通信。tcsd 守护进程是 TrouSers 套件的一部分,该套件可通过 trousers 软件包获得。TPM 2.0 较新近且向后不兼容,使用不同的软件堆栈,其中 tpm2-toolsibm-tss 实用程序提供对专用硬件的访问。

此外,用户可以使用特定的 TPM 平台配置寄存器 (PCR) 值集密封可信密钥。PCR 包含一组完整性管理值,它们反映了固件、引导装载程序和操作系统。这意味着 PCR 密封的密钥只能被加密的同一系统上的 TPM 解密。但是,一旦加载了 PCR 密封的可信密钥(添加至密钥环),并且验证其关联的 PCR 值后,就可以使用新的(或将来)PCR 值进行更新,以便可以引导新的内核。单个密钥也可以保存为多个 Blob,每个密钥都有不同的 PCR 值。

加密密钥不需要 TPM,因为它们使用内核高级加密标准 (AES),这使其比可信密钥快。加密的密钥是使用内核生成的随机数字创建的,并在导入到用户空间 Blob 时由主密钥加密。主密钥可以是可信密钥或用户密钥。如果主密钥不被信任,加密的密钥的安全性仅与用于加密它的用户密钥一样安全。

11.5. 使用可信密钥

下面的部分论述了如何使用 keyctl 实用程序创建、导出、加载或更新可信密钥来提高系统安全性。

先决条件

流程

  1. 要使用 TPM 创建可信密钥,请执行:

    # keyctl add trusted <name> "new <key_length> [options]" <key_ring>
    • 根据语法,构建如下示例命令:

      # keyctl add trusted kmk "new 32" @u
      642500861

      命令创建一个名为 kmk 的可信密钥,长度为 32 字节(256 位),并将其放置在用户密钥环 (@u) 中。密钥长度为 32 到 128 字节(256 到 1024 位)。

  2. 列出内核 keyring 的当前结构:

    # keyctl show
    Session Keyring
           -3 --alswrv    500   500  keyring: _ses
     97833714 --alswrv    500    -1   \_ keyring: _uid.1000
    642500861 --alswrv    500   500       \_ trusted: kmk
  3. 要将密钥导出到用户空间 blob,请执行:

    # keyctl pipe 642500861 > kmk.blob

    命令使用 pipe 子命令和 kmk 的序列号。

  4. 要从 user-space blob 加载可信密钥,请使用 add 子命令并将 blob 用作参数:

    # keyctl add trusted kmk "load `cat kmk.blob`" @u
    268728824
  5. 根据 TPMsealed 可信密钥创建安全加密密钥:

    # keyctl add encrypted <pass:quotes[name]> "new [format] <pass:quotes[key_type]>:<pass:quotes[primary_key_name]> <pass:quotes[keylength]>" <pass:quotes[key_ring]>
    • 根据语法,使用已创建的可信密钥生成加密密钥:

      # keyctl add encrypted encr-key "new trusted:kmk 32" @u
      159771175

      命令使用上一步中生成的 TPM 密封可信密钥 (kmk),作为生成加密密钥的主密钥

11.6. 使用加密密钥

下面的部分论述了在无法使用受信任的平台模块 (TPM) 的系统中管理加密密钥以提高系统安全性。

先决条件

  • 对于 64 位 ARM 架构和 IBM Z,需要载入 encrypted-keys 内核模块。有关如何载入内核模块的更多信息,请参阅 管理内核模块

流程

  1. 使用随机数字序列来生成用户密钥:

    # keyctl add user kmk-user "$(dd if=/dev/urandom bs=1 count=32 2>/dev/null)" @u
    427069434

    命令生成名为 kmk-user 的用户密钥,该密钥充当 主密钥,用于密封实际加密的密钥。

  2. 使用上一步中的主密钥生成加密密钥:

    # keyctl add encrypted encr-key "new user:kmk-user 32" @u
    1012412758
  3. 另外,还可列出指定用户密钥环中的所有密钥:

    # keyctl list @u
    2 keys in keyring:
    427069434: --alswrv  1000  1000 user: kmk-user
    1012412758: --alswrv  1000  1000 encrypted: encr-key
重要

请记住,未通过可信主密钥密封的加密密钥仅作为用于加密它们的用户主密钥(随机数字密钥)安全。因此,主用户密钥应该尽可能安全地加载,最好是在引导过程早期加载。

其它资源

11.7. 启用完整性测量架构和扩展验证模块

完整性测量架构 (IMA) 和扩展验证模块 (EVM) 属于内核完整性子系统,以各种方式增强系统安全性。下面的部分论述了如何启用和配置 IMA 和 EVM 来提高操作系统的安全性。

先决条件

  • 验证 securityfs 文件系统是否已挂载到 /sys/kernel/security/ 目录,并且存在 /sys/kernel/security/integrity/ima/ 目录。

    # mount
    …​
    securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
    …​
  • 验证 systemd 服务管理器是否已在引导时支持 IMA 和 EVM:

    # dmesg | grep -i -e EVM -e IMA
    [    0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet
    [    0.000000] kvm-clock: cpu 0, msr 23601001, primary cpu clock
    [    0.000000] Using crashkernel=auto, the size chosen is a best effort estimation.
    [    0.000000] Kernel command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet
    [    0.911527] ima: No TPM chip found, activating TPM-bypass!
    [    0.911538] ima: Allocated hash algorithm: sha1
    [    0.911580] evm: Initialising EVM extended attributes:
    [    0.911581] evm: security.selinux
    [    0.911581] evm: security.ima
    [    0.911582] evm: security.capability
    [    0.911582] evm: HMAC attrs: 0x1
    [    1.715151] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy)
    [    3.824198] fbcon: qxldrmfb (fb0) is primary device
    [    4.673457] PM: Image not found (code -22)
    [    6.549966] systemd[1]: systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy)

流程

  1. 添加以下内核命令行参数:

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="ima_policy=appraise_tcb ima_appraise=fix evm=fix"

    该命令在 fix 模式下为当前引导条目启用 IMA 和 EVM,并允许用户收集和更新 IMA 测量。

    ima_policy=appraise_tcb 内核命令行参数确保内核使用默认的可信计算基础 (TCB) 测量策略和实例步骤。禁止访问文件,因为之前和当前测量结果不匹配。

  2. 重启以使更改生效。
  3. (可选)验证参数是否已添加到内核命令行中:

    # cat /proc/cmdline
    BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet ima_policy=appraise_tcb ima_appraise=fix evm=fix
  4. 创建一个内核主密钥来保护 EVM 密钥:

    # keyctl add user kmk "$(dd if=/dev/urandom bs=1 count=32 2> /dev/null)" @u
    748544121

    内核主密钥 (kmk) 完全保留在内核空间内存中。内核主密钥 kmk 的 32 字节长值是从 /dev/urandom 文件中随机字节生成的,并放置在用户 (@u) 密钥环中。密钥序列号是位于前面输出的第二行。

  5. 根据 kmk 密钥创建一个加密的 EVM 密钥:

    # keyctl add encrypted evm-key "new user:kmk 64" @u
    641780271

    命令使用 kmk 生成并加密 64 字节长用户密钥(名为 evm-key)并将其放置在用户 (@u) 密钥环中。密钥序列号是位于前面输出的第二行。

    重要

    用户密钥必须命名为 evm-key,因为它是 EVM 子系统预期使用的且正在使用的名称。

  6. 为导出的密钥创建一个目录:

    # mkdir -p /etc/keys/
  7. 搜索 kmk 键并将其值导出到文件中:

    # keyctl pipe $(keyctl search @u user kmk) > /etc/keys/kmk

    命令将内核主密钥 (kmk) 的未加密值放在之前定义的位置 (/etc/keys/) 的文件中。

  8. 搜索 evm-key 用户密钥并将其值导出到文件中:

    # keyctl pipe $(keyctl search @u encrypted evm-key) > /etc/keys/evm-key

    命令将用户 evm-key 密钥的加密值放在任意位置的文件中。evm-key 已在早期由内核主密钥加密。

  9. 另外,还可查看新创建的密钥:

    # keyctl show
    Session Keyring
    974575405   --alswrv     0        0      keyring: _ses
    299489774   --alswrv     0    65534       \_ keyring: _uid.0
    748544121   --alswrv     0        0           \_ user: kmk
    641780271   --alswrv     0        0           \_ encrypted: evm-key

    您应该可以看到类似的输出。

  10. 激活 EVM:

    # echo 1 > /sys/kernel/security/evm
  11. (可选)验证 EVM 是否已初始化:

    # dmesg | tail -1
    […​] evm: key initialized

11.8. 使用完整性测量架构收集文件哈希

完整性测量架构 (IMA) 的第一级操作是测量阶段,它允许创建文件哈希并将其存储为这些文件的扩展属性 (xattrs)。下面的部分论述了如何创建和检查文件的哈希。

先决条件

  • 启用完整性测量架构(IMA)和扩展的验证模块(EVM),如 启用完整性测量架构和扩展的验证模块 中所述。
  • 验证是否已安装 ima-evm-utilsattrkeyutils 软件包:

    # yum install ima-evm-utils attr keyutils
    Updating Subscription Management repositories.
    This system is registered to Red Hat Subscription Management, but is not receiving updates. You can use subscription-manager to assign subscriptions.
    Last metadata expiration check: 0:58:22 ago on Fri 14 Feb 2020 09:58:23 AM CET.
    Package ima-evm-utils-1.1-5.el8.x86_64 is already installed.
    Package attr-2.4.48-3.el8.x86_64 is already installed.
    Package keyutils-1.5.10-7.el8.x86_64 is already installed.
    Dependencies resolved.
    Nothing to do.
    Complete!

流程

  1. 创建测试文件:

    # echo <Test_text> > test_file

    IMA 和 EVM 确保分配了示例文件 test_file,哈希值存储为其扩展属性。

  2. 检查文件的扩展属性:

    # getfattr -m . -d test_file
    # file: test_file
    security.evm=0sAnDIy4VPA0HArpPO/EqiutnNyBql
    security.ima=0sAQOEDeuUnWzwwKYk+n66h/vby3eD
    security.selinux="unconfined_u:object_r:admin_home_t:s0"

    前面的输出显示了与 SELinux 以及 IMA 和 EVM 哈希值相关的扩展属性。EVM 主动添加 security.evm 扩展属性,并检测对其他文件(如 security.ima )的 xattrs 的任何脱机篡改,它们与文件的内容完整性直接相关。security.evm 字段的值位于基于 Hash 的消息身份验证代码 (HMAC-SHA1) 中,该身份验证代码由 evm-key 用户密钥生成。

第 12 章 使用 LUKS 加密块设备

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

12.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

12.2. RHEL 中的 LUKS 版本

在 RHEL 中,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)解决方案使用。当检测到 luksmeta 元数据时,cryptsetup 工具会拒绝转换设备。
  • 设备正在活跃。该设备必须处于不活跃状态,才能进行转换。

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

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

checksum

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

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

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

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

如果 LUKS2 重新加密进程意外被强行终止,LUKU2 可通过以下方法执行恢复:

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

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

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

先决条件

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

    警告

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

流程

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

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

    • 如果是加密逻辑卷,您可以扩展逻辑卷而无需调整文件系统的大小。例如:

      # lvextend -L+32M vg00/lv00
    • 使用分区管理工具(如 parted )扩展分区。
    • 缩小该设备的文件系统。您可以对 ext2、ext3 或 ext4 文件系统使用 resize2fs 工具。请注意,您无法缩小 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) 手册页

12.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) 手册页

12.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) 手册页

12.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

其它资源

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

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

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

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

网络绑定磁盘加密(NBDE)是 PBD 的一个子类,允许将加密的卷绑定到特殊的网络服务器。NBDE 的当前实现包括 Tang 服务器的 Clevis pin 和 Tang 服务器本身。

13.1. 网络绑定磁盘加密

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

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

RHEL 安全指南 453350 0717 ECE NBDE

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

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

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

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

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

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

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

LUKS 版本 2(LUKS2)是 RHEL 中的默认磁盘加密格式,因此 NBDE 的调配状态作为令牌存储在 LUKS2 标头中。luksmeta 软件包对 NBDE 的调配状态的利用只用于使用 LUKS1 加密的卷。

Tang 的 Clevis pin 支持 LUKS1 和 LUKS2,不需要规范。Clevis 可以加密纯文本文件,但您必须使用 cryptsetup 工具来加密块设备。如需更多信息,请参阅 使用 LUKS 加密块设备

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

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

注意

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

13.2. 安装加密客户端 - Clevis

使用此流程可以在您的系统上部署并开始使用 Clevis 可插拔框架。

流程

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

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

    $ clevis decrypt < secret.jwe

其它资源

  • cllevis(1) 手册页
  • 输入不带任何参数的 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

13.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 already defined 错误消息。

  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) 手册页

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

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

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

先决条件

  • Tang 服务器正在运行。
  • clevisclevis-luks 软件包已安装在您的客户端上。
  • 请注意,RHEL 8.2 中已引入了clevis luks listclevis luks reportclevis 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. 使用 /usr/libexec/tangd-keygen 命令,在Tang 服务器上的 /var/db/tang 中生成新的密钥:

    # /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)clevis-luks-report(1)clevis-luks-regen(1) 手册页

13.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
    # grubby --update-kernel=ALL --args="rd.neednet=1"
    # 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

13.6. 基本的 NBDE 和 TPM2 加密客户端操作

Clevis 框架可以加密纯文本文件,并解密 JSON Web 加密(JWE)格式的密文和 LUKS 加密的块设备。Clevis 客户端可以使用 Tang 网络服务器或受信任的平台模块 2.0(TPM 2.0)芯片进行加密操作。

以下命令通过包含纯文本文件的示例演示了 Clevis 提供的基本功能。您还可以使用它们来对 NBDE 或 Clevis+TPM 部署进行故障排除。

绑定到 Tang 服务器的加密客户端

  • 要检查 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 输出文件包含您的加密密码文本,格式为 JWE。此密码文本是从 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"}'
  • 要解密数据,请使用 clevis decrypt 命令,并提供密码文本(JWE):

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

使用 TPM 2.0 加密客户端

  • 要使用 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
  • 要解密数据,请提供 JSON Web 加密(JWE)格式的密码文本:

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

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

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

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

PCR 中的哈希值可以重写,您无法再解锁加密的卷。因此,添加一个强大的密码短语,以便您手动解锁加密的卷,即使 PCR 中的值发生了变化。

如果在升级 shim-x64 软件包后系统无法自动解锁加密的卷,请遵照 重启后,Clevis TPM2 不再解密 LUKS 设备 KCS 文章中的步骤进行操作。

其它资源

  • clevis-encrypt-tang(1)clevis-luks-unlockers(7)clevis(1)clevis-encrypt-tpm2(1) 手册页
  • 不带任何参数的 clevisclevis decryptclevis encrypt tang 命令会显示内置 CLI 帮助信息,例如:

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

13.7. 配置 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 参数和 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
    注意

    您还可以通过使用安装了 Clevis 的系统上的 grubby 工具,确保在早期引导时 Tang pin 的网络可用:

    # grubby --update-kernel=ALL --args="rd.neednet=1"

    然后您可以使用不带 --hostonly-cmdlinedracut

    # 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"

或者,在 /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"

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

# dracut -fv --regenerate-all

其它资源

13.8. 使用 TPM 2.0 策略配置 LUKS 加密卷的手动注册

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

先决条件

  • 一个可访问的 TPM 2.0 兼容设备。
  • 具有 64 位 Intel 或 64 位 AMD 架构的系统。

流程

  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 命令将卷绑定到 TPM 2.0 设备,例如:

    # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha1","key":"rsa"}'
    ...
    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 命令占用了其中一个插槽。

      或者,如果您要将数据封装为特定的平台配置寄存器(PCR)状态,请在 clevis luks bind 命令中添加 pcr_bankpcr_ids 值,例如:

      # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha1","key":"rsa","pcr_bank":"sha1","pcr_ids":"0,1"}'
      警告

      由于只有 PCR 哈希值与密封时使用的策略匹配,并且可以重写哈希时,数据才会被解封,因此添加一个强大的密码短语,以便您可以在 PCR 中的值变化时手动解锁加密的卷。

      如果在升级 shim-x64 软件包后系统无法自动解锁加密的卷,请遵照 重启后,Clevis TPM2 不再解密 LUKS 设备 KCS 文章中的步骤进行操作。

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

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

验证

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

    # clevis luks list -d /dev/sda2
    1: tpm2 '{"hash":"sha1","key":"rsa"}'

其它资源

  • clevis-luks-bind(1)clevis-encrypt-tpm2(1)dracut.cmdline(7) 手册页

13.9. 手动从 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. 检查卷(例如 /dev/sda2)由哪个 LUKS 版本加密,并标识绑定到 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 字符串,请使用 luksmeta wipe 命令执行这个额外步骤:

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

    # cryptsetup luksKillSlot /dev/sda2 1

其它资源

  • clevis-luks-unbind(1)cryptsetup(8)luksmeta(8) 手册页

13.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 的系统需要更复杂的配置,例如:

    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 软件包:

    %packages
    clevis-dracut
    clevis-luks
    clevis-systemd
    %end
  3. (可选)要确保您可以在需要时手动解锁加密的卷,请在删除临时密码短语前添加更强的密码短语。如需更多信息,请参阅 如何给现有 LUKS 设备添加密语、密钥或 keyfile 的文章。
  4. %post 部分中调用 clevis luks bind 来执行绑定。之后,删除临时密码:

    %post
    clevis luks bind -y -k - -d /dev/vda2 \
    tang '{"url":"http://tang.srv"}' <<< "temppass"
    cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
    dracut -fv --regenerate-all
    %end

    如果您的配置依赖于在早期引导过程中需要网络的 Tang pin,或者使用带有静态 IP 配置的 NBDE 客户端,那么您必须修改dracut 命令,如 配置 LUKS 加密卷的手动注册 中所述。

    请注意,RHEL 8.3 提供了 clevis luks bind 命令的 -y 选项。在 RHEL 8.2 及更旧版本中,在 clevis luks bind 命令中将 -y 替换为 -f,并从 Tang 服务器下载公告:

    %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"
    dracut -fv --regenerate-all
    %end
    警告

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

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

其它资源

13.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) 手册页

13.12. 部署高可用性 NBDE 系统

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

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

13.12.1. 使用 Shamir 的 Secret 共享的高可用性 NBDE

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

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

13.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。

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

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

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

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

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

其它资源

  • Tang(8)高可用性 部分)、clevis(1)Shamir 的 Secret 共享 部分)和 clevis-encrypt-sss(1) 手册页

13.13. NBDE 网络中虚拟机的部署

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

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

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

注意

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

其它资源

  • clevis-luks-bind(1) 手册页

13.14. 使用 NBDE 为云环境构建可自动注册的虚拟机镜像

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

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

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

云环境支持我们在这里考虑的两种 Tang 服务器部署选项。首先,Tang 服务器可以在云环境本身中部署。其次,Tang 服务器可以部署在云外的独立的基础架构上,并且这两个基础架构之间有 VPN 连接。

在云中原生部署 Tang 可以轻松部署。但是,考虑到它与其他系统的密文数据持久性层共享基础设施,因此 Tang 服务器的私钥和 Clevis 元数据可以存储在同一个物理磁盘上。对这个物理磁盘的访问允许密文数据的完全泄露。

重要

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

13.15. 将 Tang 部署为容器

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

先决条件

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

流程

  1. registry.redhat.io 注册表中拉取 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/rhel{ProductNumber}/rhel{ProductNumber}-tang

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

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

    # podman run --rm -v tang-keys:/var/db/tang registry.redhat.io/rhel{ProductNumber}/rhel{ProductNumber}-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)手册页

13.16. Clevis 和 Tang 系统角色介绍

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

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

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

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

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

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

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

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

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

其它资源

  • 有关网络绑定磁盘加密(NBDE)角色变量的详细参考,请安装 rhel-system-roles 软件包,并查看 /usr/share/doc/rhel-system-roles/nbde_client//usr/share/doc/rhel-system-roles/nbde_server/ 目录中的 README.mdREADME.html 文件。
  • 关于系统角色 playbook 示例,请安装 rhel-system-roles 软件包,并查看 /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ 目录。
  • 有关 RHEL 系统角色的更多信息,请参阅 RHEL 系统角色简介

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

按照以下步骤准备和应用包含您的 Tang 服务器设置的 Ansible playbook。

先决条件

  • 对一个或多个 受管节点 的访问和权限,这些节点是您要使用 nbde_server 系统角色配置的系统。
  • 对控制节点的访问和权限,这是 Red Hat Ansible Engine 配置其他系统的系统。

    在控制节点上:

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

流程

  1. 准备包含 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
  2. 在您选择的文本编辑器中编辑 playbook,例如:

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

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

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

在安装了 Clevis 的系统上使用 grubby 工具来确保 Tang pin 的网络可用:

# grubby --update-kernel=ALL --args="rd.neednet=1"

其它资源

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

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

按照步骤准备和应用包含 Clevis 客户端设置的 Ansible playbook。

注意

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

先决条件

  • 对一个或多个 受管节点 的访问和权限,这些节点是您要使用 nbde_client 系统角色配置的系统。
  • 对控制节点的访问和权限,这是 Red Hat Ansible Engine 配置其他系统的系统。

    在控制节点上:

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

流程

  1. 准备包含 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
  2. 在您选择的文本编辑器中编辑 playbook,例如:

    # vi my-clevis-playbook.yml
  3. 添加所需参数。以下 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:
        - rhel-system-roles.nbde_client
  4. 应用完成的 playbook:

    # ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml
重要

在安装了 Clevis 的系统上使用 grubby 工具来确保在早期引导期间 Tang pin 的网络可用:

# grubby --update-kernel=ALL --args="rd.neednet=1"

其它资源

  • 有关 nbde_client 系统角色的参数和其他信息,请安装 rhel-system-roles 软件包,并查看 /usr/share/doc/rhel-system-roles/nbde_client//usr/share/ansible/roles/rhel-system-roles.nbde_client/ 目录。

13.19. 其它资源

第 14 章 审计系统

审计不会为您的系统提供额外的安全,而是用于发现系统上使用的安全策略的违规。可以通过其他安全措施(如 SELinux)进一步防止这些违规。

14.1. Linux 审计

Linux 审计系统提供了一种方式来跟踪系统上与安全相关的信息。根据预配置的规则,审计会生成日志条目,来尽可能多地记录系统上所发生的事件的相关信息。对于关键任务环境而言至关重要,可用来确定安全策略的违反者及其所执行的操作。

以下列表总结了审计可以在其日志文件中记录的一些信息:

  • 事件的日期、时间、类型和结果.
  • 主题和对象的敏感度标签。
  • 事件与触发事件的用户身份的关联。
  • 对审计配置的所有修改,以及对访问审计日志文件的尝试。
  • 所有身份验证机制的使用,如 SSH 和 Kerberos 等。
  • 对任何受信任数据库的修改,如 /etc/passwd
  • 尝试将信息导入系统或从系统导出。
  • 根据用户身份、主题和对象标签以及其他属性包含或排除事件。

审计系统的使用也是许多安全相关认证的一项要求。审计旨在满足或超出以下认证或合规指南的要求:

  • 受控访问保护配置文件(CAPP)
  • 标记的安全保护配置文件(LSPP)
  • 规则集基本访问控制(RSBAC)
  • 国家工业安全计划操作手册(NISPOM)
  • 联邦信息安全管理法案(FISMA)
  • 支付卡行业 - 数据安全标准(PCI-DSS)
  • 安全技术实施指南(STIG)

审计还包括:

  • 由国家信息保障合作伙伴(NIAP)和最佳安全行业(BSI)评估。
  • Red Hat Enterprise Linux 5 上的 LSPP/CAPP/RSBAC/EAL4+ 认证.
  • Red Hat Enterprise Linux 6 上的操作系统保护配置文件/评估保障级别 4+(OSPP/EAL4+)认证.

使用案例

监视文件访问
审计可以跟踪文件或目录是否已被访问、修改、执行或文件属性是否已被改变。例如,这有助于检测对重要文件的访问,并在其中一个文件损坏时提供审计跟踪。
监控系统调用
可将审计配置为在每次使用特定系统调用时生成日志条目。例如,这可用于通过监控 settimeofdayclock_adjtime 和其他与时间相关的系统调用来跟踪对系统时间的修改。
记录用户运行的命令
审计可以跟踪文件是否已被执行,因此可以定义一个规则以记录每次特定命令的执行。例如,可以对 /bin 目录中的每个可执行文件定义一个规则。然后,可以按用户 ID 搜索生成的日志条目,以生成每个用户所执行的命令的审计跟踪。
记录系统路径名称的执行
除了观察在规则调用时将路径转换为 inode 的文件访问之外,审计现在还可以观察路径的执行,即使路径在规则调用中不存在,或者在规则调用后文件被替换了。这允许规则在升级程序可执行文件后或甚至在其安装之前继续运行。
记录安全事件
pam_faillock 认证模块能够记录失败的登录尝试。也可以将审计设置为记录失败的登录尝试,并提供试图登录的用户的额外信息。
搜索事件
审计提供了 ausearch 工具,可用于过滤日志条目,并根据多个条件提供完整的审计跟踪。
运行总结报告
aureport 实用程序可用于生成记录事件的日常报告等。然后,系统管理员可以分析这些报告,并进一步调查可疑的活动。
监控网络访问
nftablesiptablesebtables 工具可以配置为触发审计事件,使系统管理员能够监控网络访问。
注意

系统性能可能会受到影响,具体取决于审计所收集的信息量。

14.2. 审计系统架构

审计系统由两个主要部分组成:用户空间应用程序和工具,以及内核端系统调用处理。内核组件接收用户空间应用程序的系统调用,并通过以下过滤器对其进行过滤:usertaskfstypeexit

系统调用通过 exclude 过滤器后,它将通过上述其中一个过滤器发送,该过滤器根据审计规则配置将其发送到审计守护进程,以进行进一步处理。

用户空间审计守护进程从内核收集信息,并在日志文件中创建条目。其他审计用户空间工具与审计守护进程、内核审计组件或审计日志文件进行交互:

  • auditctl - 审计控制工具与内核审计组件进行交互,以管理规则并控制事件产生进程的许多设置和参数。
  • 其余的审计工具将审计日志文件的内容作为输入,并根据用户的要求生成输出。例如,aureport 工具生成所有记录的事件的报告。

在 RHEL 8 中,审计分配程序守护进程(audisp)的功能集成在审计守护进程(auditd)中。用于实时分析程序与审计事件交互的插件配置文件默认位于 /etc/audit/plugins.d/ 目录中。

14.3. 为安全环境配置 auditd

默认的 auditd 配置应该适合于大多数环境。但是,如果您的环境必须满足严格的安全策略,建议对 /etc/audit/auditd.conf 文件中的审计守护进程配置进行以下设置:

log_file
包含审计日志文件的目录(通常为 /var/log/audit/)应位于单独的挂载点上。这可以防止其他进程消耗此目录的空间,并为审计守护进程提供准确的剩余空间检测。
max_log_file
指定单个审计日志文件的最大大小,必须设置为充分利用保存审计日志文件的分区上的可用空间。
max_log_file_action
一旦达到 max_log_file 中设置的限制,决定要采取什么行动,应将其设置为 keep_logs,以防止审计日志文件被覆盖。
space_left
指定磁盘上剩余的可用空间量,其是space_left_action参数中设置的触发时所采取的操作。必须设置一个数字,让管理员有足够的时间来响应,并释放磁盘空间。space_left 的值取决于审计日志文件的生成速度。
space_left_action
建议将 space_left_action 参数设置为 email 或 使用适当通知方法的 exec
admin_space_left
指定绝对最小可用空间量,其是 admin_space_left_action 参数中设置的触发时所采取的操作,必须设置一个值,为记录管理员所执行的操作保留足够的空间。
admin_space_left_action
应设置为 single 来将系统置于单用户模式,并允许管理员释放一些磁盘空间。
disk_full_action
指定当保存审计日志文件的分区上没有可用空间时触发的操作,必须设置为 haltsingle。当审计无法记录事件时,这可确保系统关闭或以单用户模式运行。
disk_error_action
指定当在包含审计日志文件的分区上检测到错误时触发的操作,必须设置为 syslogsinglehalt,具体取决于您处理硬件故障的本地安全策略。
flush
应设置为 incremental_async。它与 freq 参数相结合,该参数决定了在强制与硬盘进行硬盘同步前可以将多少条记录发送到磁盘。freq 参数应设置为100。这些参数可确保审计事件数据与磁盘上的日志文件同步,同时保持良好的活动性能。

其余配置选项应根据您的本地安全策略来设置。

14.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
在其之前被暂停后重新恢复审计事件记录,例如,当保存审计日志文件的磁盘分区中没有足够的可用空间时。
condrestarttry-restart
只有当 auditd 运行时才重新启动它。
status
显示 auditd 的运行状态。
注意

service命令是与 auditd 守护进程正确交互的唯一方法。您需要使用 service 命令,以便正确记录 auid 值。您只将 systemctl 命令用于两个操作: enablestatus

14.5. 了解审计日志文件

默认情况下,审计系统将日志条目存储在 /var/log/audit/audit.log 文件中;如果启用了日志轮转,则轮转的 audit.log 文件也在存储同一个目录中。

添加以下审计规则,来记录读取或修改 /etc/ssh/sshd_config 文件的每次尝试:

# auditctl -w /etc/ssh/sshd_config -p warx -k sshd_config

如果 auditd 守护进程正在运行,使用以下命令在审计日志文件中创建新事件,例如:

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=value 对组成,它们之间由空格或逗号分开。对上述事件的详细分析如下:

第一条记录

type=SYSCALL
type 字段包含记录的类型。在本例中,SYSCALL 值指定此记录是由对内核的系统调用触发的。
msg=audit(1364481363.243:24287):

msg 字段记录:

  • 记录的时间戳和唯一 ID,格式为 audit(time_stamp:ID)。如果多个记录是作为同一审计事件的一部分而产生的,则它们共享相同的时间戳和 ID。时间戳使用 Unix 时间格式 - 自 1970 年 1 月 1 日 00:00:00 UTC 以来的秒数。
  • 由内核或用户空间应用程序提供的各种特定于事件的 name=value 对。
arch=c000003e
arch 字段包含系统的 CPU 架构信息。该值 c000003e 以十六进制表示法编码。当使用 ausearch 命令搜索审计记录时,请使用 -i--interpret 选项来自动将十六进制值转换成人类可读的等效值。c000003e 值被解释为 x86_64
syscall=2
syscall字段记录了发送到内核的系统调用的类型。值 2 可以与 /usr/include/asm/unistd_64.h 文件中人类可读的等效值匹配。在本例中,2打开 系统调用。请注意,ausyscall 工具允许您将系统调用号转换为人类可读的等效值。使用 ausyscall --dump 命令显示所有系统调用及其编号的列表。如需更多信息,请参阅 ausyscall(8)手册页。
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 是父进程(如 bash)的 PPID 。
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 值。时间戳使用 Unix 时间格式 - 自 1970 年 1 月 1 日 00:00:00 UTC 以来的秒数。
cwd="/home/user_name"
cwd 字段包含系统调用所在目录的路径。

第三条记录

type=PATH
在第三条记录中,type 字段值为 PATH。审计事件包含作为参数传递给系统调用的每个路径的 PATH 类型记录。在这个审计事件中,只有一个路径(/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 inode 号相关联的文件或目录:

find / -inum 409248 -print
/etc/ssh/sshd_config
dev=fd:00
dev 字段指定了包含该事件中记录的文件或目录的设备的次要和主要 ID。在本例中,值表示 /dev/fd/0 设备。
mode=0100600
mode 字段记录文件或目录权限,由数字标记。它是 st_mode 字段中的 stat 命令返回。如需更多信息,请参阅 stat(2) 手册页。在这种情况下,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 字段记录了用于调用分析过程的命令的完整命令行。该字段采用十六进制表示法编码,不允许用户影响审计日志解析器。对触发此审计事件的命令进行文本解码。当使用 ausearch 命令搜索审计记录时,请使用 -i--interpret 选项来自动将十六进制值转换成人类可读的等效值。636174002F6574632F7373682F737368645F636F6E666967 值解释为 cat /etc/ssh/sshd_config

14.6. 使用 auditctl 来定义和执行审计规则

审计系统根据一组规则进行操作,这些规则定义日志文件中所捕获的内容。使用 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) 手册页。

14.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

14.8. 使用预配置的规则文件

/usr/share/audit/sample-rules 目录中,audit 软件包根据各种认证标准提供了一组预配置的规则文件:

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) 手册页。

14.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-config30-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) 手册页。

14.10. 禁用 augenrules

使用以下步骤来禁用 augenrules 工具。这会将审计切换为使用 /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

其它资源

14.11. 设置审计来监控软件更新

在 RHEL 8.6 及更高版本中,您可以使用预配置的规则 44-installers.rules 配置审计,来监控安装软件的以下工具:

  • dnf

    注意

    由于dnf 在 RHEL 中是符号链接,因此 dnf 审计规则中的路径必须包含符号链接的目标。要接收正确的审计事件,请通过将 path=/usr/bin/dnf 路径改为 /usr/bin/dnf-3 来修改 44-installers.rules 文件。

  • yum
  • pip
  • npm
  • cpan
  • gem
  • luarocks

默认情况下,rpm 在安装或更新软件包时就已提供审计 SOFTWARE_UPDATE 事件。您可以通过在命令行上输入 ausearch -m SOFTWARE_UPDATE 来列出它们。

在 RHEL 8.5 和更早版本中,您可以手动添加规则来监控工具,这些工具将软件安装到 /etc/audit/rules.d/ 目录中的 .rules 文件中。

注意

预配置的规则文件不能用于 ppc64leaarch64 架构的系统。

先决条件

流程

  1. 在 RHEL 8.6 及更高版本中,将 /usr/share/audit/sample-rules/ 目录中的预配置的规则文件 44-installers.rules 复制到 /etc/audit/rules.d/ 目录中:

    # cp /usr/share/audit/sample-rules/44-installers.rules /etc/audit/rules.d/

    在 RHEL 8.5 及更早版本中,在 /etc/audit/rules.d/ 目录中创建一个名为 44-installers.rules 的新文件,并插入以下规则:

    -a always,exit -F perm=x -F path=/usr/bin/dnf-3 -F key=software-installer
    -a always,exit -F perm=x -F path=/usr/bin/yum -F

    您可以使用相同的语法为安装软件的其他工具,如 pipnpm 添加额外的规则。

  2. 加载审计规则:

    # augenrules --load

验证

  1. 列出载入的规则:

    # auditctl -l
    -p x-w /usr/bin/dnf-3 -k software-installer
    -p x-w /usr/bin/yum -k software-installer
    -p x-w /usr/bin/pip -k software-installer
    -p x-w /usr/bin/npm -k software-installer
    -p x-w /usr/bin/cpan -k software-installer
    -p x-w /usr/bin/gem -k software-installer
    -p x-w /usr/bin/luarocks -k software-installer
  2. 执行安装,例如:

    # dnf reinstall -y vim-enhanced
  3. 在审计日志中搜索最近的安装事件,例如:

    # ausearch -ts recent -k software-installer
    ––––
    time->Thu Dec 16 10:33:46 2021
    type=PROCTITLE msg=audit(1639668826.074:298): proctitle=2F7573722F6C6962657865632F706C6174666F726D2D707974686F6E002F7573722F62696E2F646E66007265696E7374616C6C002D790076696D2D656E68616E636564
    type=PATH msg=audit(1639668826.074:298): item=2 name="/lib64/ld-linux-x86-64.so.2" inode=10092 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=PATH msg=audit(1639668826.074:298): item=1 name="/usr/libexec/platform-python" inode=4618433 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=PATH msg=audit(1639668826.074:298): item=0 name="/usr/bin/dnf" inode=6886099 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpm_exec_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=CWD msg=audit(1639668826.074:298): cwd="/root"
    type=EXECVE msg=audit(1639668826.074:298): argc=5 a0="/usr/libexec/platform-python" a1="/usr/bin/dnf" a2="reinstall" a3="-y" a4="vim-enhanced"
    type=SYSCALL msg=audit(1639668826.074:298): arch=c000003e syscall=59 success=yes exit=0 a0=55c437f22b20 a1=55c437f2c9d0 a2=55c437f2aeb0 a3=8 items=3 ppid=5256 pid=5375 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="dnf" exe="/usr/libexec/platform-python3.6" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="software-installer"

14.12. 使用审计监控用户登录时间

要监控特定时间哪个用户登录了,您不需要以任何特殊的方式配置审计。您可以使用 ausearchaureport 工具,它们提供不同的方法来展示相同的信息。

先决条件

流程

要显示用户登录的时间,请使用以下命令之一:

  • 在审计日志中搜索 USER_LOGIN 消息类型:

    # ausearch -m USER_LOGIN -ts '12/02/2020' '18:00:00' -sv no
    time->Mon Nov 22 07:33:22 2021
    type=USER_LOGIN msg=audit(1637584402.416:92): pid=1939 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="(unknown)" exe="/usr/sbin/sshd" hostname=? addr=10.37.128.108 terminal=ssh res=failed'
    • 您可以使用 -ts 选项指定日期和时间。如果不使用这个选项,ausearch 将提供从当天开始的结果,如果您省略时间,ausearch 将提供从午夜开始的结果。
    • 您可以使用 -sv yes 选项来过滤成功的登录尝试,-sv no 用来过滤失败的登录尝试。
  • ausearch 命令的原始输出传送给 aulast 工具,它以类似于 last 命令的输出格式显示输出。例如:

    # ausearch --raw | aulast --stdin
    root     ssh          10.37.128.108    Mon Nov 22 07:33 - 07:33  (00:00)
    root     ssh          10.37.128.108    Mon Nov 22 07:33 - 07:33  (00:00)
    root     ssh          10.22.16.106     Mon Nov 22 07:40 - 07:40  (00:00)
    reboot   system boot  4.18.0-348.6.el8 Mon Nov 22 07:33
  • 使用 aureport 命令及 --login -i 选项来显示登录事件列表。

    # aureport --login -i
    
    Login Report
    ============================================
    # date time auid host term exe success event
    ============================================
    1. 11/16/2021 13:11:30 root 10.40.192.190 ssh /usr/sbin/sshd yes 6920
    2. 11/16/2021 13:11:31 root 10.40.192.190 ssh /usr/sbin/sshd yes 6925
    3. 11/16/2021 13:11:31 root 10.40.192.190 ssh /usr/sbin/sshd yes 6930
    4. 11/16/2021 13:11:31 root 10.40.192.190 ssh /usr/sbin/sshd yes 6935
    5. 11/16/2021 13:11:33 root 10.40.192.190 ssh /usr/sbin/sshd yes 6940
    6. 11/16/2021 13:11:33 root 10.40.192.190 /dev/pts/0 /usr/sbin/sshd yes 6945

其它资源

  • ausearch(8) 手册页。
  • aulast(8) 手册页。
  • aureport(8) 手册页。

第 15 章 使用 fapolicyd 阻止和允许应用程序

根据规则集设置和强制实施允许或拒绝应用程序执行的策略,可有效防止执行未知的和具有潜在恶意的软件。

15.1. fapolicyd 简介

fapolicyd 软件框架根据用户定义的策略来控制应用程序的执行。这是防止在系统上运行不受信任的和可能具有恶意的应用程序的最有效的方法之一。

fapolicyd 框架提供以下组件。

  • fapolicyd 服务
  • fapolicyd 命令行工具
  • fapolicyd RPM 插件
  • fapolicyd 规则语言

管理员可以为任何应用程序定义 allowdeny 执行规则,并根据路径、哈希、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)。

其它资源

15.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

15.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. 将您的自定义二进制文件标记为可信:

    # 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) 手册页。

15.4. 为 fapolicyd 添加自定义 allow 和 deny 规则

fapolicyd 包中的默认规则集不影响系统功能。对于自定义场景,例如将二进制文件和脚本存储在非标准目录中,或者不使用 yumrpm 安装程序来添加应用程序,您必须修改现有的规则或添加新规则。以下步骤演示了如何添加新的规则以允许自定义二进制文件。

先决条件

  • fapolicyd 框架部署在您的系统上。

流程

  1. 将自定义二进制文件复制到所需的目录中,例如:

    $ cp /bin/ls /tmp
    $ /tmp/ls
    bash: /tmp/ls: Operation not permitted
  2. 停止 fapolicyd 服务:

    # systemctl stop fapolicyd
  3. 使用 debug 模式来识别相应的规则。因为 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 来停止 debug 模式:

    # 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) 手册页。

15.5. 启用 fapolicyd 完整性检查

默认情况下,fapolicyd 不执行完整性检查。您可以配置 fapolicyd,来通过比较文件大小或 SHA-256 哈希执行完整性检查。您还可以使用完整性度量架构(IMA)子系统来设置完整性检查。

先决条件

  • fapolicyd 框架部署在您的系统上。

流程

  1. 在您选择的文本编辑器中打开 /etc/fapolicyd/fapolicyd.conf 文件,例如:

    # vi /etc/fapolicyd/fapolicyd.conf
  2. integrity 选项的值从 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

15.7. 其它资源

  • 使用 man -k fapolicyd 命令列出与 fapolicyd 相关的手册页。
  • FOSDEM 2020 fapolicyd 演示。

第 16 章 保护系统免受入侵 USB 设备的攻击

USB 设备可以通过欺骗软件、恶意软件或特洛伊加载,这可能会窃取数据或损坏您的系统。作为 Red Hat Enterprise Linux 管理员,您可以使用USBGuard 来防止此类 USB 攻击。

16.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 选项(推荐)或 IPCAllowedUsersIPCAllowedGroups 选项,来限制对 IPC 接口的访问。

确保您没有未配置 Access Control List(ACL),因为这会将 IPC 接口公开给所有本地用户,允许他们操作 USB 设备的授权状态,并修改 USBGuard 策略。

16.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)usbguard-daemon.conf(5) 手册页。

16.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 使用 blockreject 术语,其含义如下:

  • block :暂时不要与此设备进行交互。
  • reject :如果设备不存在就忽略它。

其它资源

  • usbguard(1) 手册页。
  • 使用 usbguard --help 命令列出内置的帮助信息。

16.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 使用术语 blockreject,其含义如下:

  • block :暂时不要与此设备进行交互。
  • reject :如果设备不存在就忽略它。

验证

  1. 检查 USBGuard 规则是否包含您所做的更改。

    # usbguard list-rules

其它资源

  • usbguard(1) 手册页。
  • 使用 usbguard --help 命令列出内置的帮助信息。

16.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. 使用您选择的文本编辑器编辑 rules.conf 文件,例如:

    # vi ./rules.conf
  3. 根据需要添加、删除或编辑规则。例如,以下规则只允许带有一个大容量存储接口的设备与系统进行交互:

    allow with-interface equals { 08:*:* }

    有关详细的规则语言描述和更多示例,请参阅 usbguard-rules.conf(5)手册页。

  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) 手册页。

16.6. 为 USB 设备创建结构化自定义策略

您可以在 /etc/usbguard/rules.d/ 目录中的多个.conf 文件中组织自定义的 USBGuard 策略。然后 usbguard-daemon 将主 rules.conf 文件与目录中的 .conf 文件按字母顺序组合在一起。

先决条件

  • usbguard 服务已安装并运行。

流程

  1. 创建一个授权当前连接的 USB 设备的策略,并将生成的规则保存到一个新的 .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 文件中。

    注意

    文件名开头的两位数字指定守护进程读取配置文件的顺序。

    例如,将键盘的规则复制到一个新的 .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/ 目录中的 rules.conf 文件以及所有.conf 文件的内容。

    # cat /etc/usbguard/rules.conf /etc/usbguard/rules.d/*.conf
  3. 验证活动的规则是否包含文件中的所有规则,并且顺序正确。

其它资源

  • usbguard-rules.conf(5) 手册页。

16.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 modify,list --exceptions ALL

    若要删除对 joesec 用户授予的权限,可使用 usbguard remove-user joesec 命令。

  4. 重启 usbguard 守护进程以应用您的更改:

    # systemctl restart usbguard

其它资源

  • usbguard(1)usbguard-rules.conf(5) 手册页。

16.8. 将 USBguard 授权事件记录到 Linux 审计日志中

使用以下步骤将 USBguard 授权事件记录集成到标准的 Linux 审计日志中。默认情况下,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 授权事件的 audit 守护进程日志,例如:

    # ausearch -ts recent -m USER_DEVICE

其它资源

  • usbguard-daemon.conf(5) 手册页。

16.9. 其它资源

  • usbguard(1)usbguard-rules.conf(5)usbguard-daemon(8)usbguard-daemon.conf(5) 手册页。
  • USBGuard 主页