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 Customer Content Services

摘要

本书帮助用户和管理员学习如何保护工作站和服务器的安全,防止本地和远程入侵、利用和恶意活动的过程和做法。本文档侧重于 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的标准安全模型,即保密性、完整性和可用性。这种三层模型是评估敏感信息风险和制定安全政策的一个普遍接受的组成部分。下文将进一步详细介绍中情局的模式。

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

1.3. 加密软件和认证

Red Hat Enterprise Linux经过了多项安全认证,如FIPS 140-2Common Criteria(CC),以确保遵循行业最佳实践。

RHEL 8核心加密组件知识库文章对红帽企业级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包含了可以访问互联网流量的设备,如Web(HTTP)服务器、FTP服务器、SMTP(电子邮件)服务器和DNS服务器。

当你进行内窥式漏洞评估时,由于你是内部人员,你的地位被提升为受信任,所以你处于优势地位。这是你和你的同事登录系统后的观点。你可以看到打印服务器、文件服务器、数据库和其他资源。

这两种类型的漏洞评估会有分大区别。作为内部公司,为您提供比外部更多的特权。在大多数机构中,安全性被配置为把入侵者挡在外部。在保障组织内部安全方面做得很少(如部门防火墙、用户级访问控制和内部资源的认证程序)。通常情况下,在内部寻找的时候,资源会多很多,因为大部分系统都是公司内部的。一旦您位于公司以外,您的状态就不被信任。外界能提供给你的系统和资源通常是非常有限的。

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

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

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

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

警告

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

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

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

1.5.2. 建立漏洞评估方法

为了帮助选择脆弱性评估的工具,制定脆弱性评估方法是有帮助的。遗憾的是,目前还没有预先确定或行业认可的方法;但是,常识和最佳做法可以作为充分的指导。

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

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

1.5.3. 脆弱性评估工具

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

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

  • Nmap是一个流行的工具,可以用来查找主机系统和这些系统上的开放端口。要从AppStream仓库安装Nmap以根用户身份输入yum install nmap命令。更多信息请参见nmap(1)man 页面。
  • 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已经被发现并修复。

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

开发人员和系统管理员经常在服务器应用程序中发现可利用的错误,并将信息发布在错误跟踪和安全相关网站上,如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. 常见漏洞

开发描述备注

无密码或默认密码

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

常见于网络硬件,如路由器、防火墙、VPN和网络连接存储(NAS)设备。

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

管理员有时会在匆忙中创建特权用户账户,并将密码置空,这就为发现该账户的恶意用户创造了一个完美的入口。

默认共享密钥

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

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

IP欺骗

远程机器作为本地网络上的一个节点,发现服务器的漏洞,并安装后门程序或木马程序来控制你的网络资源。

欺骗是相当困难的,因为它涉及到攻击者预测TCP/IP序列号,以协调与目标系统的连接,但有几个工具可以帮助破解者执行这样的漏洞。

取决于目标系统运行的服务(如rshtelnet、FTP等),这些服务使用基于源的认证技术,与ssh或SSL/TLS中使用的PKI或其他形式的加密认证相比,不推荐使用这些技术。

窃听

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

这类攻击主要通过Telnet、FTP、HTTP传输等纯文本传输协议来实现。

远程攻击者必须能够访问局域网内被入侵的系统,才能进行这种攻击;通常破解者使用了主动攻击(如IP欺骗或中间人)来入侵局域网内的系统。

预防措施包括具有加密密钥交换、一次性密码或加密认证的服务,以防止密码窥探;还建议在传输过程中进行强加密。

服务漏洞

攻击者在互联网上运行的服务中发现了一个缺陷或漏洞;通过这个漏洞,攻击者控制了整个系统和它可能持有的任何数据,并可能控制网络上的其他系统。

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

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

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

应用程序漏洞

攻击者在桌面和工作站应用程序(如电子邮件客户端)中发现故障,并执行任意代码,植入木马程序以备将来入侵,或使系统崩溃。如果被入侵的工作站在网络的其他地方拥有管理权限,则可能会被进一步利用。

工作站和台式机更容易被利用,因为工作人员没有专业知识或经验来防止或发现漏洞;当他们安装未经授权的软件或打开未经请求的电子邮件附件时,必须告知个人他们正在承担的风险。

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

拒绝服务(DoS)攻击

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

美国报告的最新 DoS 问题单在 2000 年发生。几个高流量的商业和政府网站被一个协调的ping flood攻击,使用几个高带宽连接的受损系统作为僵尸,或重定向广播节点,使其无法使用。

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

使用iptables和网络入侵检测系统(如Snort)的入口过滤(IETF rfc2267)的进展,协助管理员追踪和防止分布式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.1.1. 非基于BIOS的系统安全

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

有关密码保护BIOS类程序的说明,请参见制造商的说明。

2.2. 磁盘分区

Red Hat 建议为/boot//home/tmp/var/tmp/目录创建单独的分区。每种原因都不一样,我们将针对每个部分进行讨论。

/boot
该分区是系统在启动时读取的第一个分区。用于引导你的系统进入 Red Hat Enterprise Linux 8 的引导加载器和内核映像都存储在这个分区中。这个分区不应该被加密。如果此分区包含在/中,并且该分区被加密或以其他方式变得不可用,那么您的系统将无法启动。
/home
当用户数据(/home)存储在 / 而不是独立分区中时,分区可能会填满,从而导致操作系统不稳定。此外,当你的系统升级到下一个版本的Red Hat Enterprise Linux 8时,如果你能把你的数据保存在/home分区中,就会容易很多,因为它不会在安装过程中被覆盖。如果根分区(/)损坏,您的数据可能会永远丢失。通过使用单独的分区,可以稍微多一些保护,防止数据丢失。你也可以针对这个分区进行频繁的备份。
/tmp/var/tmp/
/tmp/var/tmp/ 目录都是用来存储不需要长期存储的数据。然而,如果大量数据充斥其中一个目录,它可能会消耗你所有的存储空间。如果发生这种情况,并且这些目录存储在/内,那么你的系统可能会变得不稳定和崩溃。因此,将这些目录移入自己的分区是个好主意。
注意

在安装过程中,你可以选择加密分区。你必须提供一个密码。该口令作为解锁批量加密密钥的钥匙,用于保护分区数据的安全。

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

当安装 Red Hat Enterprise Linux 8 时,安装介质代表了系统在特定时间的快照。正因为如此,它可能没有最新的安全修复,可能会受到某些问题的影响,这些问题是在安装介质提供的系统发布后才修复的。

在安装潜在的易受攻击的操作系统时,应始终将暴露限制在最接近的必要网络区域。最安全的选择是"无网络"区,也就是在安装过程中让你的机器处于断开状态。在某些情况下,局域网或内网连接就足够了,而互联网连接的风险最大。为了遵循最佳的安全实践,在从网络上安装 Red Hat Enterprise Linux 8 时,选择离你的存储库最近的区域。

2.4. 安装所需的最低数量的软件包

最好的做法是只安装你将使用的软件包,因为你电脑上的每一个软件都有可能包含漏洞。如果你是从DVD媒体上安装的,请在安装过程中准确选择要安装的软件包。如果你发现你需要另一个包,你可以随时将其添加到系统中。

2.5. 安装后的程序

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

  • 更新你的系统。以root身份输入以下命令。

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

    要启动firewalld,以root身份输入以下命令。

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

    # systemctl disable cups

    要查看活动服务,请输入以下命令。

    $ systemctl list-units | grep service

2.6. 启用FIPS模式后安装RHEL 8系统

要启用联邦信息处理标准 (FIPS) 出版物 140-2 规定的加密模块自我检查,您必须在 FIPS 模式下操作 RHEL 8。你可以通过以下方式实现:

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

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

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

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

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

要了解合规性要求,请看Red Hat政府标准页面。

2.6.2. 启用FIPS模式安装系统

要启用联邦信息处理标准 (FIPS) 出版物 140-2 规定的加密模块自我检查,请在系统安装期间启用 FIPS 模式。

重要

Red Hat建议在启用FIPS模式的情况下安装Red Hat Enterprise Linux 8,而不是以后再启用FIPS模式。在安装过程中启用FIPS模式,可以确保系统生成的所有密钥都有FIPS认可的算法和持续的监控测试。

流程

  • 在系统安装过程中,在内核命令行中添加fips=1选项。

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

安装完成后,系统自动启动FIPS模式。

验证步骤

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

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

其它资源

2.6.3. 其它资源



[1] 由于各厂家的系统BIOS不同,有的可能不支持两种类型的密码保护,而有的可能支持一种类型而不支持另一种类型。

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

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

3.1. 全系统的加密政策

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

Red Hat Enterprise Linux 8 包含以下策略级别。

默认值

默认的全系统加密策略级别为当前的威胁模型提供安全设置。它允许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位,则可以接受。

未来

保守的安全级别,相信可以抵御任何近期的未来攻击。这个级别不允许在签名算法中使用SHA-1。如果RSA密钥和Diffie-Hellman参数至少有3072位长,则可以接受。

FIPS

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

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

这种变化反映了新的安全标准和新的安全研究。如果您必须在RHEL 8的整个生命周期内确保与特定系统的互操作性,您应该选择退出与该系统交互的组件的加密政策。

重要

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

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

注意

策略级别中描述的允许使用的特定算法和密码只有在应用程序支持的情况下才能使用。

管理加密政策的工具

要查看或更改当前系统范围内的加密策略,请使用更新-加密策略工具,例如。

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

为了确保加密策略的改变被应用,重新启动系统。

通过删除不安全的密码套件和协议来实现强大的加密默认。

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

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

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

在所有加密策略级别中,以下密码套件和协议被禁用。它们只能通过对单个应用程序的明确配置来启用。

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

在密码政策层面启用的密码套件和协议。

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

 LEGACY默认值FIPS未来

IKEv1

3DES

RC4

DH

最小值1024位

最小值2048位

最小值2048位

最少3072位3072位

RSA

最小值1024位

最小值2048位

最小值2048位

最少3072位3072位

DSA

TLS v1.0

TLS v1.1

数字签名中的SHA-1

CBC模式密码

密钥小于256位的对称密码器。

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

其它资源

  • 更多细节,请参见update-crypto-polies(8)man 页面。

3.2. 将全系统的加密策略切换到与早期版本兼容的模式。

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

警告

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

流程

  1. 要将全系统的加密策略切换到LEGACY级别,以root身份输入以下命令。

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

其它资源

  • 关于可用的加密策略级别列表,请参见update-crypto-policies(8)man 页面。

3.3. 将系统切换到 FIPS 模式

全系统的加密策略包含一个策略级别,使加密模块能够按照联邦信息处理标准(FIPS)出版物140-2的要求进行自我检查。在内部启用或禁用FIPS模式的fips-mode-setup工具使用FIPS全系统的加密策略级别。

重要

Red Hat建议在启用FIPS模式的情况下安装Red Hat Enterprise Linux 8,而不是以后再启用FIPS模式。在安装过程中启用FIPS模式,可以确保系统生成的所有密钥都有FIPS认可的算法和持续的监控测试。

流程

  1. 要在RHEL 8中把系统切换到FIPS模式。

    # fips-mode-setup --enable
    Setting system policy to FIPS
    FIPS mode will be enabled.
    Please reboot the system for the setting to take effect.
  2. 重新启动系统,让内核切换到FIPS模式。

    # reboot

验证步骤

  1. 重新启动后,可以查看FIPS模式的当前状态。

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

其它资源

3.4. 在容器中启用FIPS模式

根据联邦信息处理标准(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模式。

3.5. 使用不符合FIPS 140-2的加密技术的RHEL应用程序列表

红帽推荐使用核心加密组件集的库,因为它们保证通过所有相关的加密认证,如FIPS 140-2,同时也遵循RHEL全系统的加密策略。

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

除了下表中,在一些RHEL 8 Z-stream版本中(例如8.1.1),Firefox浏览器包已经更新,它们包含一个单独的NSS加密库副本。这样一来,红帽希望避免在补丁发布中对这样一个低级组件进行重新编译的干扰。因此,这些Firefox软件包没有使用FIPS 140-2验证的模块。

表 3.1. 使用不符合FIPS 140-2的加密技术的RHEL 8应用程序列表

应用详细内容

FreeRADIUS

RADIUS协议使用MD5

ghostscript

自己的加密技术(MD5、RC4、SHA-2、AES)来加密和解密文件

ipxe

TLS的加密栈被编译进来,但是,它没有被使用。

java-1.8.0-openjdk

完整的加密栈[a]

libica

通过CPACF指令为RSA和ECDH等各种算法提供软件回退。

Ovmf (UEFI固件), Edk2, shim.

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

perl-Digest-HMAC

HMAC, HMAC-SHA1, HMAC-MD5

perl-Digest-SHA

SHA-1, SHA-224, ...

土语

DES、RC4

samba[b]

AES、DES、RC4

valgrind

AES、哈希值[c]

[a] 在RHEL 8.1上,java-1.8.0-openjdk需要额外的手动配置才能符合FIPS标准。
[b] 从RHEL 8.3开始,samba使用符合FIPS标准的加密技术。
[c] 在软件硬件卸载操作中重新实现,如AES-NI。

3.6. 将应用程序从以下系统范围内的加密策略中排除出去。

您可以自定义应用程序使用的加密设置,最好是直接在应用程序中配置支持的密码套件和协议。

你也可以从/etc/crypto-polies/back-ends目录中删除一个与你的应用程序相关的符号链接,并用你自定义的加密设置来替换。此配置可防止使用排除后端的应用程序使用全系统的加密策略。此外,这一修改不受Red Hat支持。

3.6.1. 选择退出全系统加密政策的例子

wget

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

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

更多信息请参见wget(1)man 页面的 HTTPS (SSL/TLS) 选项部分。

curl

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

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

更多信息请参见curl(1)man 页面。

火狐

尽管在Firefox网页浏览器中不能选择退出系统范围内的加密策略,但你可以在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文件中的CiphersMACKexAlgoritmsGSSAPIKexAlgorithms部分所指定的值将不会被覆盖。更多信息请参见sshd_config(5)man 页面。

Libreswan

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

其它资源

  • 更多细节,请参见update-crypto-polies(8)man 页面。

3.7. 使用策略修改器定制全系统的加密策略。

使用此过程调整任何系统范围内的加密策略级别或完全自定义策略的某些算法或协议。

注意

从RHEL 8.2开始,可以定制全系统的加密策略。

流程

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

    # cd /etc/crypto-policies/policies/modules/
  2. 例如,为你的调整创建政策模块。

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

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

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

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

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

    # reboot

其它资源

  • 更多详情,请参见update-crypto-polies(8)man page 中的自定义策略部分和crypto-polies(7)man page 中的加密策略定义格式部分。
  • 如何在RHEL 8.2中定制加密策略一文提供了更多定制全系统加密策略的例子。

3.8. 通过自定义全系统的加密策略禁用SHA-1。

SHA-1哈希函数的设计本身就很脆弱,而密码分析的进步使它很容易受到攻击。默认情况下,RHEL 8不使用SHA-1,但一些第三方应用程序,例如公共签名,仍然使用SHA-1。要在系统中禁止在签名算法中使用SHA-1,可以使用NO-SHA1策略模块。

注意

从RHEL 8.3开始,可以使用禁用SHA-1的模块。从RHEL 8.2开始,可以定制全系统的加密策略。

流程

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

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

    # reboot

其它资源

  • 更多详情,请参见update-crypto-polies(8)man page 中的自定义策略部分和crypto-polies(7)man page 中的加密策略定义格式部分。
  • 如何在RHEL 8.2中定制加密策略的博文提供了定制全系统加密策略的其他例子。

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

其它资源

  • 更多详情,请参见update-crypto-polies(8)man page 中的自定义策略部分和crypto-polies(7)man page 中的加密策略定义格式部分。
  • 如何在RHEL 8.2中定制加密策略一文提供了更多定制全系统加密策略的例子。

第 4 章 通过PKCS #11配置应用程序以使用加密硬件。

在专用加密设备上分离部分秘密信息,如用于终端用户认证的智能卡和加密令牌,以及用于服务器应用的硬件安全模块(HSM),可提供额外的安全层。在Red Hat Enterprise Linux 8中,通过PKCS #11 API对加密硬件的支持在不同的应用中是一致的,在加密硬件上隔离秘密并不是一件复杂的事情。

4.1. 通过PKCS #11提供加密硬件支持。

PKCS #11(公钥密码学标准)定义了一个应用编程接口(API),用于存放密码信息和执行密码功能的密码设备。这些设备被称为代币,它们可以以硬件或软件的形式实现。

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

PKCS #11 URI是根据对象属性识别PKCS #11模块中特定对象的标准方式。这使得你可以用URI形式的配置字符串配置所有的库和应用程序。

Red Hat Enterprise Linux 8默认为智能卡提供OpenSC PKCS #11驱动程序。然而,硬件令牌和HSM可以拥有自己的PKCS #11模块,而这些模块在Red Hat Enterprise Linux中没有对应的模块。你可以用p11-kit工具注册这样的PKCS #11模块,它在系统中注册的智能卡驱动程序上起着包装的作用。

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

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

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

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

Red Hat Enterprise Linux 8 可让您使用保存在 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包装器,且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] $

其它资源

4.3. 在Apache和Nginx中使用HSM保护私钥。

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

ApacheHTTP服务器

对于HTTPS协议形式的安全通信,ApacheHTTP服务器(httpd)使用了OpenSSL库。OpenSSL不支持PKCS #11。要利用HSMs,你必须安装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包以获得ApacheHTTP服务器的完整文档,包括TLS配置。/etc/httpd/conf.d/ssl.conf 配置文件中的指令在 /usr/share/httpd/manual/mod_ssl.html 中有详细介绍。

NginxHTTP和代理服务器

因为Nginx也使用OpenSSL进行加密操作,所以对PKCS #11的支持必须通过openssl-pkcs11引擎。Nginx目前只支持从HSM加载私钥,证书必须作为常规文件单独提供。修改/etc/nginx/nginx.conf配置文件中服务器部分的ssl_certificatessl_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需要引擎:pkcs11:前缀。这是因为另一个pkcs11前缀指的是引擎名称。

4.4. 配置应用程序使用智能卡中的证书进行认证。

  • 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)man 页面。

  • 指定pkcs #11 URI供curl工具使用是类似的。

    $ 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)man 页面。

  • 火狐浏览器会自动加载p11-kit-proxy模块。这意味着,系统中每一张支持的智能卡都会被自动检测到。对于使用TLS客户端认证,不需要额外的设置,当服务器请求时,会自动使用智能卡中的密钥。

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

如果你的应用程序使用GnuTLSNSS库,对PKCS #11 URI的支持由它们内置的PKCS #11支持来保证。同时,由于openssl-pkcs11引擎的存在,依赖OpenSSL库的应用程序可以访问加密硬件模块。

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

更多信息请参见p11-kit(8)man 页面。

第 5 章 使用共享系统证书

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

5.1. 全系统的信托存储

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

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

  • 为信任锚

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

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

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

在分层密码系统中,信任锚是一个其他各方认为值得信赖的权威实体。在X.509架构中,根证书是一个信任锚,从这个信任锚中衍生出一条信任链。要实现链式验证,信任方必须先接入信任锚。

5.2. 添加新证书

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

先决条件

  • 系统中存在ca-certificate包。

流程

  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的情况下使用新增的证书,但Red Hat建议在更换CA后使用update-ca-trust命令。另外要注意的是,Firefox、Epiphany或Chromium等浏览器会有缓存文件,你可能需要清除浏览器的缓存或重启浏览器才能加载当前的系统证书配置。

5.3. 管理可信系统证书

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

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

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

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

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

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

其它资源

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

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

5.4. 其它资源

更多信息,请参见以下手册页面。

  • update-ca-trust(8)
  • trust(1)

第 6 章 扫描系统的配置合规性和漏洞。

合规性审计是确定某一对象是否遵循合规性政策中规定的所有规则的过程。合规性策略是由安全专业人员定义的,他们规定了计算环境应该使用的所需设置,通常以检查表的形式出现。

各个组织之间,甚至同一组织内的不同系统之间,合规政策可能有很大的不同。这些政策之间的差异是基于每个系统的目的及其对组织的重要性。自定义软件设置和部署特点也提出了对自定义策略检查表的需求。

6.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 解决方案。

其它资源

  • oscap(8)-oscap命令行实用程序的手册页面提供了一个完整的可用选项列表和它们的用法说明。
  • 红帽安全演示。创建自定义的安全策略内容,以实现安全合规性的自动化--这是一个实践性的实验室,可以获得使用Red Hat Enterprise Linux中包含的工具来实现安全合规性自动化的初步经验,以符合行业标准安全策略和自定义安全策略。如果你想为你的团队提供培训或访问这些实验室练习,请联系你的Red Hat客户团队以获得更多的细节。
  • 红帽安全演示。用RHEL安全技术来保护自己 - 这是一个实践性的实验室,让你了解如何在你的RHEL系统的各个层面上实施安全,使用Red Hat Enterprise Linux中的关键安全技术,包括OpenSCAP。如果你想为你的团队提供培训或访问这些实验室练习,请联系你的Red Hat客户团队以获得更多的细节。
  • scap-workbench(8)-SCAP Workbench应用程序的手册页面提供了有关该应用程序的基本信息以及一些指向SCAP内容潜在来源的链接。
  • scap-security-guide(8)-scap-security-guide项目的手册页面提供了关于各种可用的SCAP安全配置文件的进一步文档。此外,还提供了如何使用OpenSCAP实用程序来使用所提供的基准的例子。
  • 有关使用 Red Hat Satellite 的 OpenSCAP 的更多详情,请参阅《管理 Red Hat Satellite 指南》中的安全合规性管理

6.2. 漏洞扫描

6.2.1. 红帽安全公告 OVAL feed

Red Hat Enterprise Linux的安全审计功能是基于安全内容自动化协议(SCAP)标准的。SCAP是一个多用途的规范框架,支持自动配置、漏洞和补丁检查、技术控制合规性活动和安全测量。

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

开放式脆弱性评估语言(OVAL)是SCAP的基本和最古老的组成部分。与其他工具和自定义脚本不同,OVAL以声明的方式描述资源的所需状态。OVAL代码从不直接执行,而是使用名为scanner的OVAL解释器工具。OVAL的声明性保证了被评估系统的状态不会被意外修改。

像所有其他SCAP组件一样,OVAL是基于XML的。SCAP标准定义了几种文件格式。每一种信息都包括不同的种类,有不同的作用。

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

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

RHSA OVAL定义可以单独使用,也可以作为一个完整的软件包使用,并且在Red Hat客户门户上发布新的安全公告后一小时内更新。

每个 OVAL 补丁定义都会一对一地映射到红帽安全咨询(RHSA)。因为一个RHSA可以包含多个漏洞的修复,每个漏洞都会以其常见漏洞和暴露(CVE)的名称单独列出,并有一个链接到我们的公共错误数据库中的条目。

RHSA OVAL定义的目的是检查系统上安装的RPM包的脆弱版本。可以将这些定义扩展到包括进一步的检查,例如,找出包是否被用于易受攻击的配置中。这些定义是为了涵盖Red Hat所提供的软件和更新而设计的。检测第三方软件的补丁状态需要额外的定义。

注意

要扫描容器或容器映像是否存在安全漏洞,请参见扫描容器和容器映像是否存在漏洞

6.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. 扫描系统的漏洞,并将结果保存到漏洞.html文件中。

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

验证步骤

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

    $ firefox vulnerability.html &

其它资源

6.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. machine1主机名、SSH运行在22端口、joesec用户名扫描远程系统的漏洞,并将结果保存到远程漏洞.html文件中。

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

其它资源

6.3. 配置合规性扫描

6.3.1. RHEL 8中的配置合规性

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

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

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

重要

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

SCAP安全指南套件以数据流文件的形式为多个平台提供了配置文件。数据流是一个包含定义、基准、配置文件和个别规则的文件。每条规则都具体规定了适用性和遵守要求。RHEL 8提供了几个配置文件以符合安全策略。除了行业标准外,红帽数据流还包含对失败规则的补救信息。

合规扫描资源的结构

Data stream
   ├── xccdf
   |      ├── benchmark
   |            ├── profile
   |                ├──rule
   |                    ├── xccdf
   |                         ├── oval reference
   ├── oval                  ├── ocil reference
   ├── ocil                  ├── cpe reference
   └── cpe                   └── remediation

配置文件是基于安全策略的一组规则,如操作系统保护配置文件(OSPP)或支付卡行业数据安全标准(PCI-DSS)。这使您能够以自动方式审计系统是否符合安全标准。

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

注意

要扫描容器或容器映像以了解配置合规性,请参见扫描容器和容器映像以了解漏洞。

6.3.2. OpenSCAP扫描的可能结果

根据您系统的各种属性以及应用于OpenSCAP扫描的数据流和配置文件,每个规则都可能产生特定的结果。这是一份可能的结果清单,并对其含义作了简要解释。

表 6.1. OpenSCAP扫描的可能结果

结果解释

通行证

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

失败

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

未检查

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

不适用

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

未选择

这条规则不是档案的一部分。OpenSCAP不评估此规则,也不在结果中显示这些规则。

错误

扫描遇到了一个错误。要了解更多的信息,你可以用--verbose DEVEL选项输入oscap命令。考虑打开一个错误报告

未知

扫描时遇到了意外情况。要了解更多的信息,可以输入带`--verbose DEVEL选项的oscap命令。考虑打开一个错误报告

6.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字符串表示。在"配置文件"部分,您可以找到可用的配置文件及其ID的列表。

    $ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
    ...
    Profiles:
      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. 从数据流文件中选择一个配置文件,并显示所选配置文件的其他详细信息。要做到这一点,请使用oscap info--profile选项,后面跟着上一条命令输出中显示的 ID 的最后一部分。例如,PCI-DSS配置文件的ID是:xccdf_org.ssgproject.content_profile_pci-dss,而--profile选项的值是pci-dss

    $ oscap info --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
    ...
    Title: PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 8
    Id: xccdf_org.ssgproject.content_profile_pci-dss
    
    Description: Ensures PCI-DSS v3.2.1 security configuration settings are applied.
    ...

其它资源

  • Scap-security-guide(8)man page.

6.3.4. 评估配置是否符合特定基线

要确定您的系统是否符合特定的基线,请遵循这些步骤。

先决条件

流程

  1. 评估系统是否符合选定的配置文件,并将扫描结果保存在 report.html HTML 文件中,例如。

    $ sudo oscap xccdf eval --report report.html --profile ospp /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
  2. 可选。使用machine1主机名、SSH22 端口和joesec用户名扫描远程系统,以确定是否符合要求,并将结果保存到remote-report.html文件中。

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

其它资源

6.4. 对系统进行补救,使之与特定的基线保持一致。

使用此程序修复RHEL 8系统,使其与特定基线保持一致。本例使用通用操作系统的保护配置文件(OSPP)。

警告

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

先决条件

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

流程

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

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

验证步骤

  1. 评估系统是否符合OSPP配置文件,并将扫描结果保存在ospp_report.html文件中。

    $ oscap xccdf eval --report ospp_report.html --profile ospp /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml。

其它资源

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

6.5. 使用SSG Ansible游戏手册对系统进行修复,使其与特定基线保持一致。

使用此步骤,使用SCAP安全指南项目中的Ansible剧本文件,用特定的基线对系统进行修复。本例使用通用操作系统的保护配置文件(OSPP)。

警告

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

先决条件

  • scap-security-guide 软件包安装在 RHEL 8 系统中。
  • 安装了ansible软件包。请参阅《Ansible安装指南》了解更多信息。

流程

  1. 使用Ansible修复您的系统以与OSPP保持一致。

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

验证步骤

  1. 评估系统是否符合OSPP配置文件,并将扫描结果保存在ospp_report.html文件中。

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

其它资源

6.6. 创建一个补救Ansible游戏手册,使系统与特定的基线保持一致。

使用此过程创建 Ansible 播放簿,其中仅包含将系统与特定基线对齐所需的补救措施。本例使用通用操作系统的保护配置文件(OSPP)。通过这个程序,你可以创建一个较小的剧本,不涵盖已经满足的要求。按照这些步骤,你不会以任何方式修改你的系统,你只是为以后的应用准备一个文件。

先决条件

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

流程

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

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

    # oscap xccdf generate fix --fix-type ansible --output ospp-remediations.yml ospp-results.xml
  3. ospp-remediations.yml文件包含了针对在步骤1中执行的扫描中失败的规则的Ansible补救措施。查看完这个生成的文件后,可以用ansible-playbook ospp-remediations.yml命令进行应用。

验证步骤

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

其它资源

6.7. 为以后的应用创建一个修复的Bash脚本。

使用此过程创建一个包含补救措施的 Bash 脚本,使您的系统与 PCI-DSS 等安全配置文件保持一致。使用下面的步骤,你不会对系统进行任何修改,你只是为以后的应用准备一个文件。

先决条件

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

流程

  1. 使用oscap命令扫描系统并将结果保存到XML文件中。在下面的例子中,oscap根据pci-dss配置文件评估系统。

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

    # oscap xccdf generate fix --profile pci-dss --fix-type bash --output pci-dss-remediations.sh pci-dss-results.xml
  3. pci-dss-remediations.sh文件包含在步骤 1 中执行的扫描期间失败的规则的补救措施。审查完这个生成的文件后,当你与这个文件在同一目录下时,可以用./pci-dss-remediations.sh命令来应用它。

验证步骤

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

其它资源

  • scap-security-guide(8),oscap(8), andbash(1)man pages

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

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

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

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

先决条件

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

流程

  1. 要从GNOME经典桌面环境中运行SCAP工作台,按超级键进入"活动概览",输入scap-workbench,然后按Enter键。或者,使用:

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

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

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

    警告

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

  4. 单击"扫描"按钮,用选定的配置文件扫描系统。

    Scap 工作台结果
  5. 要以 XCCDF、ARF 或 HTML 文件的形式存储扫描结果,请单击保存结果组合框。选择"HTML报告"选项,以人类可读的格式生成扫描报告。XCCDF和ARF(数据流)格式适用于进一步的自动处理。你可以反复选择这三个选项。
  6. 要将基于结果的补救措施导出到文件,请使用"生成补救措施"弹出式菜单。

6.8.2. 使用SCAP Workbench定制安全配置文件。

您可以通过更改某些规则中的参数(例如,最小密码长度)、删除以不同方式覆盖的规则以及选择附加规则来定制安全配置文件,以执行内部策略。您不能通过自定义配置文件来定义新规则。

下面的程序演示了如何使用SCAP Workbench来定制(定制)配置文件。您也可以保存定制的配置文件,以便使用oscap命令行工具。

先决条件

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

流程

  1. 运行SCAP Workbench,并通过使用"文件"菜单中的"从SCAP安全指南中打开内容"或"打开其他内容"来选择要定制的配置文件。
  2. 要根据您的需求调整所选的安全配置文件,请单击"自定义"按钮。

    这将打开新的"自定义"窗口,使您能够在不改变原始数据流文件的情况下修改当前选定的配置文件。选择一个新的配置文件ID。

    选择您的新资料的ID
  3. 使用将规则组织成逻辑组的树形结构或搜索字段找到要修改的规则。
  4. 在树结构中使用复选框包含或排除规则,或在适用的情况下修改规则中的值。

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

    • 通过使用"文件"菜单中的"仅保存自定义"单独保存自定义文件。
    • 通过"文件"菜单中的"全部保存"一次性保存所有安全内容。

      如果选择Into a directory选项,SCAP Workbench会将数据流文件和自定义文件都保存到指定的位置。你可以把它作为一个备份方案。

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

注意

由于SCAP 工作台不支持基于结果的定制配置文件补救措施,因此使用oscap命令行工具导出补救措施。

6.9. 安装后立即部署符合安全配置文件的系统。

您可以在安装过程后立即使用OpenSCAP套件部署符合安全配置文件(如OSPP或PCI-DSS)的RHEL系统。使用这种部署方法,您可以应用以后无法使用补救脚本应用的特定规则,例如,密码强度和分区的规则。

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

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

先决条件

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

流程

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

    警告

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

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

    注意

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

验证步骤

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

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

其它资源

6.9.2. 使用 Kickstart 部署符合基线的 RHEL 系统。

使用此步骤部署与特定基线一致的 RHEL 系统。这个示例为常规目的操作系统(OSPP)使用保护配置集。

先决条件

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

流程

  1. 在你选择的编辑器中打开/usr/share/scap-security-guide/kickstart/ssg-rhel8-ospp-ks.cfgKickstart文件。
  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

其它资源

6.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. 扫描容器或容器映像是否存在漏洞,并将结果保存到漏洞.html文件中。

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

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

验证步骤

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

    $ firefox vulnerability.html &

其它资源

  • 更多信息,请参见oscap-podman(8)oscap(8)man 页面。

6.11. 用特定的基线评估容器或容器图像的安全合规性。

按照这些步骤评估您的容器或容器映像是否符合特定的安全基线,如操作系统保护配置文件 (OSPP) 或支付卡行业数据安全标准 (PCI-DSS)。

注意

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. 评估容器映像是否符合 OSPP 配置文件,并将扫描结果保存到report.htmlHTML 文件中。

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

    如果您使用 PCI-DSS 基准评估安全合规性,将 096cae65a207 替换为您的容器镜像 ID,将 ospp 值替换为 pci-dss。请注意,oscap-podman命令需要root权限。

验证步骤

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

    $ firefox report.html &
注意

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

其它资源

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

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

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

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

RHEL 6.6

scap-security-guide-0.1.18-3.el6

RHEL 6.9

scap-security-guide-0.1.28-3.el6

RHEL 6.10

scap-security-guide-0.1.28-4.el6

RHEL 7.2 AUS

scap-security-guide-0.1.25-3.el7

RHEL 7.3 AUS

scap-security-guide-0.1.30-5.el7_3

RHEL 7.4 AUS, E4S。

scap-security-guide-0.1.33-6.el7_4

RHEL 7.5 (批量更新)

scap-security-guide-0.1.36-10.el7_5

RHEL 7.6 EUS

scap-security-guide-0.1.40-13.el7_6

RHEL 7.7 EUS

scap-security-guide-0.1.43-13.el7

RHEL 7.8 (批量更新)

scap-security-guide-0.1.46-11.el7

RHEL 7.9

scap-security-guide-0.1.52-2.el7_9

RHEL 8.0 SAP

scap-security-guide-0.1.42-11.el8

RHEL 8.1 EUS

scap-security-guide-0.1.47-8.el8_1

RHEL 8.2 (批量更新)

scap-security-guide-0.1.48-10.el8_2

RHEL 8.3

scap-security-guide-0.1.50-16.el8_3

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

只使用RHEL特定小版本中提供的SCAP内容。这是因为参与加固的组件有时会更新新的功能。SCAP的内容会改变以反映这些更新,但它并不总是向后兼容。

在下面的表格中,您可以找到RHEL的每个次要版本中提供的配置文件,以及与该配置文件一致的策略版本。

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

资料名称资料ID政策版本

CIS Red Hat Enterprise Linux 8基准

xccdf_org.ssgproject.content_profile_cis

1.0.0

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

xccdf_org.ssgproject.content_profile_cui

r1

澳大利亚网络安全中心(ACSC)的基本八大要素

xccdf_org.ssgproject.content_profile_e8

没有版本

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

xccdf_org.ssgproject.content_profile_hipaa

没有版本

通用操作系统的保护简介

xccdf_org.ssgproject.content_profile_ospp

4.2.1

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

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

[草稿]《国防信息系统局红帽企业Linux 8安全技术实施指南》(DISA STIG)

xccdf_org.ssgproject.content_profile_stig

草拟

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

资料名称资料ID政策版本

澳大利亚网络安全中心(ACSC)的基本八大要素

xccdf_org.ssgproject.content_profile_e8

没有版本

通用操作系统的保护简介

xccdf_org.ssgproject.content_profile_ospp

4.2.1

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

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

[DRAFT] 红帽企业Linux 8的DISA STIG。

xccdf_org.ssgproject.content_profile_stig

草拟

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

资料名称资料ID政策版本

通用操作系统的保护简介

xccdf_org.ssgproject.content_profile_ospp

4.2.1

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

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

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

资料名称资料ID政策版本

OSPP--通用操作系统的保护配置文件

xccdf_org.ssgproject.content_profile_ospp

草拟

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

xccdf_org.ssgproject.content_profile_pci-dss

3.2.1

其它资源

第 7 章 用AIDE检查完整性

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

7.1. 安装AIDE

以下是安装AIDE和启动其数据库的必要步骤。

先决条件

  • AppStream存储库已启用。

流程

  1. 要安装助手包。

    # 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二进制文件存储在一个安全的位置,如只读媒体。

7.2. 用AIDE进行完整性检查

先决条件

流程

  1. 要启动手动检查:

    # aide --check
    Start timestamp: 2018-07-11 12:41:20 +0200 (AIDE 0.16)
    AIDE found differences between database and filesystem!!
    ...
    [trimmed for clarity]
  2. 至少应将AIDE配置为每周运行一次扫描。最多,AIDE应该每天运行。例如,如果要使用cron命令安排每天凌晨04:05执行AIDE,请在/etc/crontab文件中添加以下一行。

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

7.3. 更新AIDE数据库

在验证了您的系统变化后,如软件包更新或配置文件调整,建议更新您的基线AIDE数据库。

先决条件

流程

  1. 更新您的基线AIDE数据库。

    # aide --update

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

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

第 8 章 使用LUKS对块设备进行加密

磁盘加密通过对块设备上的数据进行加密保护。要访问设备的解密内容,用户必须提供一个口令或密钥作为认证。当涉及到移动计算机和可移动媒体时,这一点尤为重要:即使设备已从系统中物理移除,它也有助于保护设备的内容。LUKS格式是RHEL中块设备加密的默认实现。

8.1. LUKS磁盘加密

Linux Unified Key Setup-on-disk-format (LUKS)使您能够对块设备进行加密,它提供了一套工具,简化了对加密设备的管理。LUKS允许多个用户密钥解密一个主密钥,用于分区的批量加密。

RHEL利用LUKS进行块设备加密。默认情况下,在安装过程中不勾选加密块设备的选项。如果你选择了加密磁盘的选项,每次开机时系统都会提示你输入密码。这个口令可以"解锁"解密分区的批量加密密钥。如果您选择修改默认的分区表,可以选择加密哪个分区。这是在分区表设置中设置的。

LUKS是什么?

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

LUKS 不能做什么

  • 像LUKS这样的磁盘加密解决方案只在系统关闭时保护数据。一旦系统开启,LUKS对磁盘进行了解密,该磁盘上的文件就可以供任何正常访问它们的人使用。
  • LUKS并不适合需要许多用户对同一设备拥有不同访问密钥的场景。LUKS1格式提供8个键槽,LUKS2最多可提供32个键槽。
  • LUKS不适合需要文件级加密的应用。

加密系统

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

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

8.2. RHEL 8中的LUKS版本

在RHEL 8中,LUKS加密的默认格式是LUKS2。传统的LUKS1格式仍然完全支持,它是作为一种与早期RHEL版本兼容的格式提供的。

LUKS2格式的设计是为了将来能够在不需要修改二进制结构的情况下对各种部件进行更新。LUKS2内部使用JSON文本格式的元数据,提供元数据的冗余,检测元数据损坏,并允许从元数据副本中自动修复。

重要

不要在需要与仅支持LUKS1的旧系统兼容的系统中使用LUKS2。请注意,RHEL 7从7.6版本开始支持LUKS2格式。

警告

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

LUKS版本加密命令

LUKS2

加密设置重新加密

LUKS1

cryptsetup-reencrypt

在线重新加密

LUKS2格式支持在设备使用时对加密设备进行重新加密。例如,您不必卸载设备上的文件系统就可以执行以下任务。

  • 改变音量键
  • 更改加密算法

当对未加密的设备进行加密时,您仍然必须卸载文件系统。你可以在短暂的加密初始化后重新挂载文件系统。

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

换算

LUKS2格式的灵感来源于LUKS1。在某些情况下,你可以将LUKS1转换为LUKS2。具体在以下情况下无法进行转换。

  • LUKS1设备被标记为正在被基于策略的解密(PBD - Clevis)解决方案使用。当检测到一些luksmeta元数据时,cryptsetup工具拒绝转换设备。
  • 一个设备是活动的。在进行任何转换之前,该设备必须处于非活动状态。

8.3. LUKS2重新加密期间数据保护的选项

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

checksum

这是默认模式。它平衡了数据保护和性能。

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

journal
这是最安全的模式,但也是最慢的模式。该模式在二进制区域中记述了重新加密的区域,所以LUKS2写了两次数据。
none
该模式优先考虑性能,不提供数据保护。它只在安全进程终止时保护数据,如SIGTERM信号或用户按下 Ctrl+C.任何意外的系统崩溃或应用程序崩溃都可能导致数据损坏。

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

如果LUKS2重新加密过程意外强行终止,LUKS2可以通过以下方式进行恢复。

  • 在下一次打开LUKS2设备的过程中,自动进行。这个操作是由cryptsetup open命令或者通过systemd-cryptsetup附加设备来触发的。
  • 手动操作,在LUKS2设备上使用cryptsetup repair命令。

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

8.5. 使用LUKS2加密块设备上的现有数据,并附加一个头。

这个过程会对块设备上的现有数据进行加密,而不会为存储LUKS头创建空闲空间。头部存储在一个分离的位置,这也是一个额外的安全层。该程序采用LUKS2加密格式。

先决条件

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

    警告

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

流程

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

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

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

    /path/to/header替换为带有LUKS头的文件路径。分离的LUKS头必须可以访问,以便以后可以解锁加密设备。

    该命令要求你输入密码并开始加密过程。

  3. 安装设备。

    # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted
  4. 开始在线加密。

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

其它资源

  • 更多细节请参见cryptsetup(8)man 页面。

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

其它资源

  • 更多细节请参见cryptsetup(8)man 页面。

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

您可以使用存储角色通过运行Ansible剧本来创建和配置用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

其它资源

  • 如需了解更多与 LUKS 相关的信息,请参阅 17。使用 LUKS 加密块设备
  • 有关存储系统角色中使用的参数的详细信息,请参阅/usr/share/ansible/roles/rhel-system-roles.storage/README.md文件。

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

基于策略的解密(PBD)是一个技术集合,它能够解锁物理机和虚拟机上的加密硬盘根卷和辅助卷。PBD采用多种解锁方式,如用户密码、可信平台模块(TPM)设备、连接到系统的PKCS #11设备,如智能卡或特殊网络服务器。

PBD允许将不同的解锁方式结合到一个策略中,这样就可以用不同的方式解锁同一个卷。目前在Red Hat Enterprise Linux中实现的PBD由Clevis框架和称为pins的插件组成。每个针脚都提供单独的解锁功能。目前,有以下针脚。

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

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

9.1. 网络绑定的磁盘加密

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

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

RHEL安全指南 453350 0717 ECE NBDE

唐是一个将数据绑定到网络存在的服务器。它使包含你的数据的系统在绑定到一定的安全网络时可以使用。Tang是无状态的,不需要TLS或认证。与基于托管的解决方案不同,服务器存储了所有加密密钥,并且知道每一个曾经使用过的密钥,而Tang从不与任何客户端密钥进行交互,因此它永远不会从客户端获得任何身份信息。

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

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

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

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

当你开始配置NBDE时,唐服务器的Clevis针得到唐服务器的广告非对称密钥列表。另外,由于密钥是非对称的,所以可以将唐人的公钥列表分布在带外,这样客户可以在不访问唐人服务器的情况下进行操作。这种模式称为离线配置

唐的Clevis针使用其中一个公钥生成一个唯一的、加密性强的加密密钥。一旦使用该密钥对数据进行加密,该密钥就会被丢弃。Clevis客户端应该将这次供应操作产生的状态存储在一个方便的位置。这个对数据进行加密的过程就是供应步骤

LUKS版本2(LUKS2)是Red Hat Enterprise Linux 8中的默认格式,因此,NBDE的供应状态以令牌的形式存储在LUKS2头中。贸发会议对非商业化发展的供应状态的利用。 luksmeta包只用于用LUKS1加密的卷。唐人的Clevis针脚同时支持LUKS1和LUKS2,不需要任何规格。

当客户端准备好访问它的数据时,它会加载供应步骤中产生的元数据,它响应恢复加密密钥。这个过程就是恢复步骤

在NBDE中,Clevis使用针脚绑定LUKS卷,这样就可以自动解锁。成功完成绑定过程后,可以使用提供的Dracut解锁器解锁磁盘。

9.2. 安装加密客户端 - Clevis

使用此步骤在系统上部署并开始使用Clevis可插拔框架。

流程

  1. 在有加密卷的系统上安装Clevis及其引脚。

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

    $ clevis decrypt < secret.jwe

其它资源

  • 关于快速参考,请参见内置的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
  • 更多信息,请参见clevis(1)man页面。

9.3. 在强制模式下使用SELinux部署Tang服务器。

使用此过程将运行在自定义端口上的Tang服务器部署为SELinux强制模式下的限制服务。

先决条件

  • 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 definederror 消息。

  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文件,通过添加以下几行,将唐人服务器的默认端口从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)man page
  • semanage(8)man page
  • firewall-cmd(1)man page
  • systemd.unit(5)systemd.socket(5)联机手册。
  • jose(1)man page

9.4. 旋转唐朝服务器键和更新客户端上的绑定。

使用下面的步骤来轮换您的 Tang 服务器键,并更新客户端上现有的绑定。你应该轮换它们的精确间隔取决于你的应用、关键大小和机构政策。

先决条件

  • 一台唐人服务器正在运行。
  • 您的客户机上安装了clevisclevis-luks软件包。
  • 请注意,在RHEL 8.2中引入了clevis luks listclevis luks reportclevis luks regen

流程

  1. 要轮换密钥,请使用/usr/libexec/tangd-keygen命令在Tang服务器的/var/db/tang密钥数据库目录下生成新的密钥。

    # ls /var/db/tang
    UV6dqXSwe1bRKG3KbJmdiR020hY.jwk y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
    # /usr/libexec/tangd-keygen /var/db/tang
    # ls /var/db/tang
    UV6dqXSwe1bRKG3KbJmdiR020hY.jwk y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
    3ZWS6-cDrCG61UPJS2BMmPU4I54.jwk zyLuX6hijUy_PSeUEFDi7hi38.jwk
  2. 检查你的Tang服务器是否从新的密钥对中宣传签名密钥,例如。

    # tang-show-keys 7500
    3ZWS6-cDrCG61UPJS2BMmPU4I54
  3. 重新命名旧的钥匙,有一个领先的.以隐藏它们的广告。需要注意的是,下面例子中的文件名与唐人服务器的密钥数据库目录中的唯一文件名不同。

    # cd /var/db/tang
    # ls -l
    -rw-r--r--. 1 root tang 354 Sep 23 16:08 3ZWS6-cDrCG61UPJS2BMmPU4I54.jwk
    -rw-r--r--. 1 root tang 349 Sep 23 16:08 I-zyLuX6hijUy_PSeUEFDi7hi38.jwk
    -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

    唐国栋立刻接过所有的变化。不需要重新启动。此时,新的客户端绑定接上新的密钥,老客户端可以继续利用旧的密钥。

  4. 在你的NBDE客户端上,使用clevis luks报告命令来检查唐朝服务器所公布的密钥是否保持不变。例如,你可以使用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]
  5. 要为新按键重新生成LUKS元数据,可以按y键到上一条命令的提示,或者使用clevis luks regen命令。

    # clevis luks regen -d /dev/sda2 -s 1
  6. 当你确定所有的老客户都使用新的密钥时,你可以从唐人服务器上删除旧的密钥,例如。

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

当客户还在使用旧钥匙时,删除旧钥匙会导致数据丢失。如果不小心删除了这样的密钥,请在客户端使用clevis luks regen命令,并手动提供LUKS密码。

其它资源

  • tang-show-keys(1), clevis-luks-list(1), clevis-luks-report(1), and clevis-luks-regen(1) man pages

9.5. 在网络控制台中配置使用唐键的自动解锁功能

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

先决条件

  • RHEL 8网络控制台已经安装完毕。

    详情请参阅 安装 Web 控制台

  • 系统中安装了驾驶舱存储包。
  • cockpit.socket服务运行在9090端口。
  • 安装了clevistangclevis-dracut包。
  • 一台唐人服务器正在运行。

流程

  1. 在网络浏览器中输入以下地址,打开RHEL网络控制台。

    https://localhost:9090

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

  2. 提供您的凭证,然后单击"存储"。选择加密设备并点 内容部分中的 Encryption
  3. 钥匙部分点击+,添加唐键。

    RHEL web控制台。加密
  4. 提供您的Tang服务器的地址和解锁LUKS加密设备的密码。点击"添加"确认。

    RHEL网络控制台。添加唐键
  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网络控制台。验证唐键
  7. 要启用早期启动系统处理磁盘绑定,请单击左侧导航栏底部的终端,输入以下命令。

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

验证步骤

  1. 检查新添加的唐键现在已经被列在Keys部分,类型为Keyserver

    RHEL网络控制台。一个密钥服务器密钥被列出
  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

其它资源

9.6. 使用唐人街为NBDE系统部署加密客户端。

下面的步骤包含了用唐人网络服务器配置自动解锁加密卷的步骤。

先决条件

  • Clevis框架已安装完毕。
  • 有一个唐人服务器。

流程

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

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

    将前面例子中的http://tang.srv:portURL 改为与安装tang的服务器的 URL 相匹配。secret.jwe 输出文件包含了您的加密密码文本,采用 JSON Web 加密格式。这个密文是从input-plain.txt输入文件中读取的。

    另外,如果你的配置需要在没有SSH访问的情况下与唐人服务器进行非交互式通信,你可以下载一个广告并保存到文件中。

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

    adv.jws文件中的广告用于以下任何任务,例如文件或消息的加密。

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

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

其它资源

  • 关于快速参考,请参见clevis-encrypt-tang(1)man 页面或使用内置 CLI 帮助。

    $ clevis
    $ clevis decrypt
    $ clevis encrypt tang
    Usage: clevis encrypt tang CONFIG < PLAINTEXT > JWE
    ...
  • 更多信息,请参见以下手册页面。

    • clevis(1)
    • clevis-luks-unlockers(7)

9.7. 手动从LUKS加密卷中移除一个Clevis针脚。

使用下面的步骤手动删除由clevis luks bind命令创建的元数据,也可以擦除包含Clevis添加的密码口令的键槽。

重要

从LUKS加密卷中移除Clevis引脚的推荐方法是通过clevis luks unbind命令。使用clevis luks unbind的移除过程只有一个步骤,并且适用于LUKS1和LUKS2卷。以下示例命令删除绑定步骤创建的元数据,并擦拭/dev/sda2设备上的键槽1

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

先决条件

  • 一本LUKS加密卷,采用Clevis装订。

流程

  1. 检查该卷的LUKS版本,例如/dev/sda2,是由哪个版本加密的,并确定一个插槽和一个绑定到Clevis的令牌。

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

    在前面的例子中,Clevis令牌的标识为0,相关的密钥槽为1

  2. 在LUKS2加密的情况下,删除令牌。

    # cryptsetup token remove --token-id 0 /dev/sda2
  3. 如果你的设备被LUKS1加密了,在cryptsetup luksDump命令的输出中用Version: 1字符串表示,那么就用luksmeta wipe命令执行这个额外的步骤。

    # luksmeta wipe -d /dev/sda2 -s 1
  4. 擦拭含有Clevis密码的钥匙槽。

    # cryptsetup luksKillSlot /dev/sda2 1

其它资源

  • 更多信息请参见clevis-luks-unbind(1)cryptsetup(8)luksmeta(8)的手册。

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

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

先决条件

流程

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

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

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

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

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

该引脚还支持将数据封存到平台配置寄存器(PCR)状态。这样一来,只有当PCR的哈希值与封印时使用的策略相匹配时,数据才能被解封。

例如,将SHA-1库的数据用索引0和1封到PCR上。

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

其它资源

  • 关于更多的信息和可能的配置属性列表,请参见clevis-encrypt-tpm2(1)man页面。

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

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

先决条件

  • 一台唐人服务器正在运行并可用。

流程

  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头标记中,如果使用非默认的LUKS1头标记,则使用LUKSMeta。
    4. 启用新的密钥,以便与LUKS一起使用。

      注意

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

  4. 现在可以用您现有的密码以及Clevis策略来解锁音量。
  5. 要启用早期启动系统处理磁盘绑定,请在已经安装的系统上输入以下命令。

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

验证步骤

  1. 要验证Clevis JWE对象是否成功地放在LUKS头中,请使用clevis luks list命令。

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

要在静态IP配置的客户机上使用NBDE(没有DHCP),请手动将您的网络配置传递给dracut工具,例如。

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

另外,在/etc/dracut.conf.d/目录下创建一个包含静态网络信息的.conf文件。例如:

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

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

# dracut -fv --regenerate-all

其它资源

更多信息,请参见以下手册页面。

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

9.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
    %end
  3. 调用clevis luks bind来执行%post部分的绑定。之后,删除临时密码。

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

    在前面的例子中,请注意,我们将从唐人服务器上下载广告作为绑定配置的一部分,使得绑定完全没有交互性。

    警告

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

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

其它资源

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

使用此步骤设置LUKS加密USB存储设备的自动解锁过程。

流程

  1. 要自动解锁LUKS加密的可移动存储设备,例如U盘,请安装clevis-udisks2软件包。

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

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

    # clevis luks unlock -d /dev/sdb1

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

其它资源

更多信息,请看下面的手册页。

  • clevis-luks-unlockers(7)

9.12. 部署高可用性的NBDE系统

唐建国提供了两种构建高可用性部署的方法。

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

9.12.1. 使用Shamir的秘密共享的高可用NBDE

Shamir's Secret Sharing(SSS)是一种加密方案,它将一个秘密分为几个独特的部分。要想重新构建秘密,需要一些部件。这个数字称为阈值,SSS也被称为阈值化方案。

Clevis提供了SSS的实施。它创造了一把钥匙,并将其分成若干块。每一块都是用另一个引脚加密,包括甚至SSS递归。此外,你还定义了阈值t。如果一个NBDE部署至少解密了t件,那么它就会恢复加密密钥,解密过程就会成功。当Clevis检测到的零件数量少于阈值中指定的数量时,它会打印一条错误信息。

9.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命令就会成功地重建秘密。

9.12.1.2. 例2:唐人服务器和TPM设备上的共享秘密

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

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

SSS阈值't'设置为'2'的配置方案现。

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

其它资源

  • 关于推荐的高可用性 NBDE 设置的更多信息,请参见以下手册页面。

    • 堂(8)高可用性部分
    • clevis(1)Shamir's Secret Sharing部分。
    • clevis-encrypt-sss(1)

9.13. 在NBDE网络中部署虚拟机。

clevis luks bind 命令不会改变 LUKS 主密钥。这意味着,如果您创建了用于虚拟机或云环境的LUKS加密映像,所有运行该映像的实例都将共享一个主密钥。这是极不安全的,任何时候都应该避免。

这不是Clevis的局限,而是LUKS的设计原则。如果你希望在云中拥有加密的根卷,你需要确保你也为云中的每个Red Hat Enterprise Linux实例执行安装过程(通常使用Kickstart)。如果不同时共享LUKS主密钥,则无法共享图片。

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

注意

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

其它资源

更多信息,请看下面的手册页。

  • clevis-luks-bind(1)

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

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

因此,最好的做法是创建不在任何公共存储库中共享的定制图像,并为部署有限数量的实例提供基础。创建实例的确切数量应该由部署的安全策略来定义,并基于与LUKS主密钥攻击向量相关的风险容忍度。

为了构建LUKS的自动部署,应该使用Lorax或virt-install等系统和Kickstart文件来确保镜像构建过程中主密钥的唯一性。

云环境可以实现两种唐服务器的部署方案,我们在此考虑。首先,唐人服务器可以在云环境中自行部署。其次,唐人服务器可以部署在云外的独立基础设施上,两个基础设施之间有VPN连接。

在云端原生部署Tang,确实可以轻松部署。但是,考虑到它与其他系统的密文数据持久层共享基础设施,可能唐服务器的私钥和Clevis元数据都存储在同一个物理磁盘上。访问这个物理磁盘,可以对密文数据进行全面妥协。

重要

因此,Red Hat 强烈建议在存储数据的位置和运行 Tang 的系统之间保持物理隔离。这种云端和唐人服务器之间的分离,保证了唐人服务器的私钥不会意外地与Clevis元数据结合。如果云基础架构面临风险,它还可以对唐服务器进行本地控制。

9.15. 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 变量。使用现值来创建新的绑定或更新现有的绑定。与clevis luks bind命令相反,你也可以使用state: present来覆盖其设备槽中的现有绑定。absent 的值会删除指定的绑定。

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

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

其它资源

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

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

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

先决条件

流程

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

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

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

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

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

    # vi my-tang-playbook.yml
  6. 添加所需参数。下面的示例玩法确保了你的唐朝服务器的部署和关键轮换。

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

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

其它资源

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

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

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

注意

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

先决条件

流程

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

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

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

    # yum install rhel-system-roles
  4. 准备包含 Clevis 客户端设置的 playbook。你可以从头开始,或者使用/usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/目录中的一个示例playbook。

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

    # vi my-clevis-playbook.yml
  6. 添加所需参数。下面的示例演练手册配置了Clevis客户端,以便在两个Tang服务器中至少有一个可用时自动解锁两个LUKS加密卷。

    ---
    - hosts: all
    
      vars:
        nbde_client_bindings:
          - device: /dev/rhel/root
            encryption_key_src: /etc/luks/keyfile
            servers:
              - http://server1.example.com
              - http://server2.example.com
          - device: /dev/rhel/swap
            encryption_key_src: /etc/luks/keyfile
            servers:
              - http://server1.example.com
              - http://server2.example.com
    
      roles:
        - linux-system-roles.nbde_client
  7. 应用完成的 playbook:

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

其它资源

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

9.18. 其它资源

第 10 章 对系统的审计

审计并不能为您的系统提供额外的安全性;相反,它可以用来发现系统上使用的违反安全策略的行为。这些违规行为可以通过额外的安全措施(如SELinux)进一步防止。

10.1. Linux审计

Linux审计系统提供了一种跟踪系统上安全相关信息的方法。根据预先配置的规则,Audit会生成日志条目,以尽可能多地记录系统上发生的事件信息。这些信息对于关键任务环境来说至关重要,可以确定违反安全策略的人和他们的行为。

以下列表总结了Audit能够记录在其日志文件中的一些信息。

  • 事件的日期和时间、类型和结果。
  • 主体和客体的敏感性标签。
  • 事件与触发事件的用户身份的关联。
  • 所有对审计配置的修改和访问审计日志文件的尝试。
  • 所有使用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的文件访问外,Audit现在可以观察路径的执行情况,即使在规则调用时该路径并不存在,或者在规则调用后文件被替换。这允许规则在升级程序可执行文件后或甚至安装之前继续工作。
记录安全事件
pam_faillock 认证模块能够记录失败的登录尝试。审计也可以设置为记录失败的登录尝试,并提供有关尝试登录的用户的额外信息。
搜索活动
Audit提供了ausearch实用程序,它可以用来过滤日志条目,并根据几个条件提供完整的审计跟踪。
运行摘要报告
aureport 实用程序可用于生成记录事件的日常报告等。然后,系统管理员可以分析这些报告并进一步调查可疑活动。
监测网络访问
iptablesebtables 实用程序可以配置为触发审计事件,允许系统管理员监控网络访问。
注意

系统性能可能会受到影响,这取决于审计部门收集的信息量。

10.2. 审计系统结构

审计系统主要由两部分组成:用户空间的应用程序和实用程序,以及内核侧的系统调用处理。内核组件接收来自用户空间应用程序的系统调用,并通过以下过滤器之一进行过滤:用户任务fstype退出

一旦系统调用通过了排除过滤器,就会通过上述的一个过滤器,根据审计规则的配置,将其发送到审计守护进程进行进一步处理。

用户空间Audit守护进程收集来自内核的信息,并在日志文件中创建条目。其他Audit用户空间实用程序与Audit守护进程、内核Audit组件或Audit日志文件交互。

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

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

10.3. 为安全环境配置审计d

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

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

其余的配置选项应根据当地的安全策略进行设置。

10.4. 启动和控制审计d

配置好auditd后,启动服务收集Audit信息并存储在日志文件中。以root用户身份使用以下命令启动auditd

service auditd start

要配置auditd在启动时启动。

systemctl enable auditd

可以使用service auditdaction命令对auditd进行一些其他的操作,其中action可以是以下之一。

stop
停止审计d
restart
重新开始审核d
reloadforce-reload
/etc/audit/auditd.conf文件中重新加载auditd的配置。
转动
旋转/var/log/audit/目录下的日志文件。
简历
在之前暂停后恢复审计事件的记录,例如,当存放审计日志文件的磁盘分区上没有足够的可用空间时。
condrestarttry-restart
只有在审计d已经运行的情况下才会重新启动它。
status
显示auditd的运行状态。
注意

service命令是与 auditd 守护进程正确交互的唯一方法。您需要使用service命令来正确记录auid值。你只能使用systemctl命令进行两个操作:启用状态

10.5. 了解审计日志文件

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

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

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

例如,如果auditd守护进程正在运行,使用以下命令在 Audit 日志文件中创建一个新的事件。

cat /etc/ssh/sshd_config

audit.log 文件中的该事件如下。

type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"
type=CWD msg=audit(1364481363.243:24287):  cwd="/home/shadowman"
type=PATH msg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0  nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1364481363.243:24287) : proctitle=636174002F6574632F7373682F737368645F636F6E666967

上述事件由四条记录组成,它们具有相同的时间戳和序列号。记录总是以type=关键字开始。每条记录由多个名称=对组成,中间用空格或逗号隔开。下面对上述事件进行详细分析。

第一记录

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

msg 字段记录:

  • 时间戳和记录的唯一ID,形式为audit(time_stamp:ID)。如果多条记录是作为同一审计事件的一部分产生的,它们可以共享相同的时间戳和ID。时间戳使用Unix时间格式--自1970年1月1日00:00:00 UTC以来的秒数。
  • 内核或用户空间应用程序提供的各种特定事件名称=对。
arch=c000003e
arch 字段包含系统的 CPU 架构信息。该值c000003e以十六进制符号编码。当使用ausearch命令搜索 Audit 记录时,使用-i--interpret选项自动将十六进制值转换为人可读的等值。c000003e 值被解释为 x86_64
syscall=2
syscall字段记录了发送到内核的系统调用的类型。值2可以与/usr/include/asm/unistd_64.h文件中的人类可读等价物匹配。在这种情况下,2开放系统调用。请注意,ausyscall实用程序允许您将系统呼叫号码转换为人类可读的等价物。使用ausyscall --dump命令显示所有系统呼叫及其号码的列表。更多信息,请参见ausyscall(8) man 页面。
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)。在这种情况下,3538过程的PID。
auid=1000
auid字段记录了审计用户 ID,即loginuid。这个ID是在用户登录时分配给用户的,即使用户的身份发生了变化,例如用su - john命令切换用户账户,这个ID也会被每个进程继承。
uid=1000
uid 字段记录了启动分析过程的用户的用户 ID。用户ID可以用以下命令解释为用户名:ausearch -i --uidUID
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命令被用来触发这个Audit事件。
exe="/bin/cat"
exe 字段记录了用于调用分析过程的可执行文件的路径。
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
subj 字段记录了被分析的进程在执行时被标记的 SELinux 上下文。
key="sshd_config"
key 记录了与在审计日志中生成该事件的规则相关联的管理员定义的字符串。

第二个记录

type=CWD

在第二条记录中,类型字段值是CWD--当前工作目录。该类型用于记录工作目录,从该目录中调用第一个记录中指定的系统调用的进程被执行。

该记录的目的是记录当前进程的位置,以防相关路径最终被相关的PATH记录捕获。这样就可以重建绝对路径。

msg=audit(1364481363.243:24287)
msg 字段持有与第一条记录中的值相同的时间戳和 ID 值。时间戳使用Unix时间格式--自1970年1月1日00:00:00 UTC以来的秒数。
cwd="/home/user_name"
cwd 字段包含系统调用所在目录的路径。

第三次记录

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

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

10.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)man 页面以获取更多信息、性能提示和其他使用示例。

10.7. 定义持久的审计规则

要定义在重启过程中保持不变的审计规则,必须直接将其包含在 /etc/audit/rules.d/audit.rules 文件中,或者使用 augenrules 程序读取位于/etc/audit/rules.d/ 目录中的规则。

需要注意的是,/etc/audit/audit.rule文件是在每当audd服务启动时生成的。/etc/audit/rules.d/ 中的文件使用相同的 auditctl 命令行语法来指定规则。空行和哈希符号(#)后面的文本将被忽略。

此外,你可以使用auditctl命令从指定的文件中读取规则,例如使用-R选项。

# auditctl -R /usr/share/audit/sample-rules/30-stig.rules

10.8. 使用预先配置的规则文件

/usr/share/audit/sample-rules目录下,审计包根据各种认证标准提供了一套预配置的规则文件。

30-nispom.rules
符合《国家工业安全计划操作手册》信息系统安全一章规定的审计规则配置。
30-ospp-v42*.rules
符合OSPP(通用操作系统保护规范)配置文件4.2版本中定义的要求的审计规则配置。
30-pci-dss-v31.rules
符合支付卡行业数据安全标准(PCI DSS)v3.1规定的审计规则配置。
30-stig.rules
符合《安全技术实施指南》(STIG)规定的审计规则配置。

要使用这些配置文件,请将它们复制到/usr/share/audit/sample-rules目录下,然后使用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)man 页面了解更多信息、故障排除和其他使用示例。

10.9. 使用augenrules定义持久性规则。

augenrules脚本读取位于/etc/audit/rules.d/目录下的规则,并将它们编译成audit.rures文件。这个脚本根据自然排序顺序,以特定顺序处理所有以.rule结尾的文件。本目录中的文件按以下含义分成几组:

  • 10 - 内核和 auditctl 配置
  • 20 - 可与常规规则匹配但您希望不同匹配的规则
  • 30 - 主要规则
  • 40 - 任择规则
  • 50 - 服务器专用规则
  • 70 - 系统本地规则
  • 90 - 最终确定(不可更改)

这些规则并不是要一次性使用的。它们是政策的一部分,应该想好,并将各个文件复制到/etc/audit/rules.d/。例如,要在STIG配置中设置系统,复制规则10-base-config30-stig31-privileged99-finalize

一旦你在/etc/audit/rules.d/目录下有了规则,就可以通过运行augenrules脚本和--load指令来加载它们。

# augenrules --load
/sbin/augenrules: No change
No rules
enabled 1
failure 1
pid 742
rate_limit 0
...

其它资源

  • 关于审计规则和augenrules脚本的更多信息,请参见audit.rule(8)augenrules(8)man 页面。

10.10. 禁用augenrules

使用以下步骤禁用augenrules实用程序。这将使 Audit 使用/etc/audit/audit.rules文件中定义的规则。

流程

  1. /usr/lib/systemd/system/auditd.service文件复制到/etc/systemd/system/目录下。

    # cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/
  2. 在你选择的文本编辑器中编辑/etc/systemd/system/auditd.service文件,例如。

    # vi /etc/systemd/system/auditd.service
  3. 删去包含augenrules的行,取消包含audctl -R命令的行。

    #ExecStartPost=-/sbin/augenrules --load
    ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
  4. 重新启动systemd守护进程以获取审计d.service文件中的变化。

    # systemctl daemon-reload
  5. 重新启动审计d服务。

    # service auditd restart

其它资源

第 11 章 阻止和允许使用fapolicyd的应用程序。

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

11.1. Fapolicyd简介

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

fapolicyd 框架提供以下组件。

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

管理员可以为任何应用程序定义允许拒绝执行规则,并可以根据路径、哈希、MIME类型或信任进行审计。

fapolicyd 框架引入了信任的概念。当一个应用程序被系统包管理器正确安装时,它就被信任了,因此它被注册在系统RPM数据库中。fapolicyd 守护进程使用 RPM 数据库作为受信任的二进制文件和脚本的列表。fapolicyd YUM 插件注册任何由 YUM 包管理器处理的系统更新。该插件会通知fapolicyd守护进程关于该数据库的变化。

使用rpm工具安装需要手动刷新数据库,而其他添加应用程序的方式则需要创建自定义规则并重新启动fapolicyd服务。

fapolicyd 服务配置位于 /etc/fapolicyd/ 目录中,结构如下。

  • fapolicyd.rules 文件包含了允许拒绝执行规则。
  • fapolicyd.conf文件包含守护进程的配置选项。这个文件主要用于性能调整的目的。

其它资源

  • 请参阅 fapolicyd(8),fapolicyd.rule(5)fapolicyd.conf(5)联机手册了解更多信息。

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

11.3. 使用额外的信任来源将文件标记为受信任的文件。

您可以使用此过程为fapolicyd使用额外的信任源。在RHEL 8.3之前,fapolicyd只信任RPM数据库中的文件。fapolicyd 框架现在也支持使用 /etc/fapolicyd/fapolicyd.trust 纯文本文件作为信任源。你可以直接用文本编辑器或通过fapolicydCLI命令修改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

    # systemctl restart fapolicyd

验证步骤

  1. 检查你的自定义二进制现在可以执行,例如。

    $ /tmp/ls
    ls

其它资源

  • 更多信息请参见fapolicyd.trust(5)man 页面。

11.4. 为fapolicyd添加自定义允许和拒绝规则。

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

先决条件

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

流程

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

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

    # systemctl stop fapolicyd
  3. 使用调试模式来确定相应的规则。因为fapolicyd --debug命令的输出是冗长的,你只能通过按下 Ctrl+C或杀死相应的进程,将错误输出重定向到一个文件。

    # fapolicyd --debug 2> fapolicy.output &
    [1] 51341

    另外,你也可以在另一个终端中运行fapolicyd调试模式。

  4. 重复未被允许的命令。

    $ /tmp/ls
    bash: /tmp/ls: Operation not permitted
  5. 在前台恢复调试模式并按下 Ctrl+C:

    # fg
    fapolicyd --debug
    ^Cshutting down...
    Inter-thread max queue depth 1
    Allowed accesses: 2
    Denied accesses: 1
    [...]

    或者,杀死fapolicyd调试模式的进程。

    # 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.rule文件中添加以下规则,允许执行/tmp目录下的所有二进制文件。

    allow perm=execute exe=/usr/bin/bash trust=1 : dir=/tmp/ all trust=0
  8. 为了防止您的自定义二进制的内容发生变化,请使用SHA-256校验和定义所需的规则。

    $ sha256sum /tmp/ls
    780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836  ls

    将该规则改为以下定义:

    allow perm=execute exe=/usr/bin/bash trust=1 : sha256hash=780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836
  9. 启动fapolicyd服务。

    # systemctl start fapolicyd

验证步骤

  1. 检查你的自定义二进制现在可以执行,例如。

    $ /tmp/ls
    ls

其它资源

  • 更多信息请参见fapolicyd.trust(5)man 页面。

11.6. 其它资源

  • 更多信息请参见使用man -k fapolicyd 命令列出的 fapolicyd 相关 man 页面。
  • FOSDEM 2020 fapolicyd 演示提供了几个添加自定义 fapolicyd 规则的例子。

第 12 章 保护系统免受USB设备的入侵

USB设备可能加载了间谍软件、恶意软件或木马程序,从而窃取你的数据或破坏你的系统。作为Red Hat Enterprise Linux的管理员,你可以用USBGuard来防止这种USB攻击。

12.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接口的访问。

确保您不要未配置访问控制列表 (ACL),因为这将 IPC 接口暴露给所有本地用户,并允许他们操纵 USB 设备的授权状态和修改 USBGuard 策略。

12.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)andusbguard-daemon.conf(5)man pages

12.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使用的阻塞拒绝术语具有以下含义。

  • 阻止:暂时不要与该设备进行交互。
  • 拒绝:忽略这个设备,好像它不存在一样。

其它资源

  • 列出usbguard命令的所有选项。

    $ usbguard --help
  • usbguard(1)man page

12.4. 永久封堵并授权USB设备。

您可以使用-p选项永久封堵并授权USB设备。这将为当前策略添加一个特定设备的规则。

先决条件

  • usbguard 服务已安装并运行。

流程

  1. 配置SELinux,允许usbguard守护进程编写规则。

    1. 显示与usbguard相关的语义布尔。

      # 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具有以下含义。

  • 阻止:暂时不要与该设备进行交互。
  • 拒绝:忽略这个设备,好像它不存在一样。

验证

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

    # usbguard list-rules

其它资源

  • 列出usbguard命令的所有选项。

    $ usbguard --help
  • usbguard(1)man page

12.5. 为USB设备创建自定义策略

以下程序包含为USB设备创建规则集的步骤,该规则集反映了您的场景要求。

先决条件

  • usbguard 服务已安装并运行。
  • /etc/usbguard/rules.conf 文件包含了由usbguard generate-policy 命令生成的初始规则集。

流程

  1. 创建一个授权当前连接的USB设备的策略,并将生成的规则存储到rule.conf文件中。

    # usbguard generate-policy --no-hashes > ./rules.conf

    --no-hashes 选项不会为设备生成哈希属性。在配置设置中避免使用哈希属性,因为它们可能不会持久化。

  2. 用你选择的文本编辑器编辑rule.conf文件,例如。

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

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

    请参阅usbguard-rules.conf(5)man 页面,了解详细的规则语言描述和更多的例子。

  4. 安装更新后的政策。

    # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf
  5. 重新启动usbguard守护进程来应用你的更改。

    # systemctl restart usbguard

验证步骤

  1. 检查您的自定义规则是否在活动策略中,例如。

    # usbguard list-rules
    ...
    4: allow with-interface 08:*:*
    ...

其它资源

  • usbguard-rules.conf(5)man page

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

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

先决条件

  • usbguard 服务已安装并运行。

流程

  1. 创建一个授权当前连接的USB设备的策略,并将生成的规则存储到一个新的.conf文件中,例如。 政策.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. 将剩下的行移到主规则.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. 显示rules.conf文件的内容以及/etc/usbguard/rules.d/目录下的所有.conf文件。

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

其它资源

  • usbguard-rules.conf(5)man page

12.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. 例如,添加一行规则,允许轮组中的所有用户使用IPC接口,并保存文件。

    IPCAllowGroups=wheel
  3. 您也可以使用usbguard命令添加用户或组。例如,下面的命令使joesec用户能够完全访问DeviceExceptions部分。此外,joesec还可以列出当前的政策并监听政策信号。

    # usbguard add-user joesec --devices ALL --policy list,list listen --exceptions ALL

    要删除joesec用户的权限,请使用usbguard remove-user joesec命令。

  4. 重新启动usbguard守护进程来应用你的更改。

    # systemctl restart usbguard

其它资源

  • usbguard(1)andusbguard-rules.conf(5)man pages

12.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授权事件。

    # ausearch -ts recent -m USER_DEVICE

其它资源

  • usbguard-daemon.conf(5)man page

12.9. 其它资源

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

法律通告

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

为了尽快向用户提供最新的信息,本文档可能会包括由机器自动从英文原文翻译的内容。如需更多信息,请参阅此说明。