来自 Linux 基金会内部的《Linux 工作站安全检查清单》
================================================================================

### 目标受众

	这是一套 Linux 基金会为其系统管理员提供的推荐规范。

这个文档用于帮助那些使用 Linux 工作站来访问和管理项目的 IT 设施的系统管理员团队。

如果你的系统管理员是远程员工，你也许可以使用这套指导方针确保系统管理员的系统可以通过核心安全需求，降低你的IT 平台成为攻击目标的风险。

即使你的系统管理员不是远程员工，很多人也会在工作环境中通过便携笔记本完成工作，或者在家中设置系统以便在业余时间或紧急时刻访问工作平台。不论发生何种情况，你都能调整这个推荐规范来适应你的环境。


### 限制

但是，这并不是一个详细的“工作站加固”文档，可以说这是一个努力避免大多数明显安全错误而不会导致太多不便的一组推荐基线（baseline）。你也许阅读这个文档后会认为它的方法太偏执，而另一些人也许会认为这仅仅是一些肤浅的研究。安全就像在高速公路上开车 -- 任何比你开的慢的都是一个傻瓜，然而任何比你开的快的人都是疯子。这个指南仅仅是一些列核心安全规则，既不详细又不能替代经验、警惕和常识。

我们分享这篇文档是为了[将开源协作的优势带到 IT 策略文献资料中][18]。如果你发现它有用，我们希望你可以将它用到你自己团体中，并分享你的改进，对它的完善做出你的贡献。

### 结构

每一节都分为两个部分：

- 核对适合你项目的需求
- 形式不定的提示内容，解释了为什么这么做

#### 严重级别

在清单的每一个项目都包括严重级别，我们希望这些能帮助指导你的决定：

- **关键（ESSENTIAL）** 该项应该在考虑列表上被明确的重视。如果不采取措施，将会导致你的平台安全出现高风险。
- **中等（NICE）** 该项将改善你的安全形势，但是会影响到你的工作环境的流程，可能会要求养成新的习惯，改掉旧的习惯。
- **低等（PARANOID）** 留作感觉会明显完善我们平台安全、但是可能会需要大量调整与操作系统交互的方式的项目。

记住，这些只是参考。如果你觉得这些严重级别不能反映你的工程对安全的承诺，你应该调整它们为你所合适的。

## 选择正确的硬件

我们并不会要求管理员使用一个特殊供应商或者一个特殊的型号，所以这一节提供的是选择工作系统时的核心注意事项。

### 检查清单

- [ ] 系统支持安全启动（SecureBoot） _(关键)_
- [ ] 系统没有火线（Firewire），雷电（thunderbolt）或者扩展卡（ExpressCard）接口 _(中等)_
- [ ] 系统有 TPM 芯片 _(中等)_

### 注意事项

#### 安全启动（SecureBoot）

尽管它还有争议，但是安全引导能够预防很多针对工作站的攻击（Rootkits、“Evil Maid”，等等），而没有太多额外的麻烦。它并不能阻止真正专门的攻击者，加上在很大程度上，国家安全机构有办法应对它（可能是通过设计)，但是有安全引导总比什么都没有强。

作为选择，你也许可以部署 [Anti Evil Maid][1] 提供更多健全的保护，以对抗安全引导所需要阻止的攻击类型，但是它需要更多部署和维护的工作。

#### 系统没有火线（Firewire），雷电（thunderbolt）或者扩展卡（ExpressCard）接口

火线是一个标准，其设计上允许任何连接的设备能够完全地直接访问你的系统内存（参见[维基百科][2]）。雷电接口和扩展卡同样有问题，虽然一些后来部署的雷电接口试图限制内存访问的范围。如果你没有这些系统端口，那是最好的，但是它并不严重，它们通常可以通过 UEFI 关闭或内核本身禁用。

#### TPM 芯片

可信平台模块（Trusted Platform Module ，TPM）是主板上的一个与核心处理器单独分开的加密芯片，它可以用来增加平台的安全性（比如存储全盘加密的密钥），不过通常不会用于日常的平台操作。充其量，这个是一个有则更好的东西，除非你有特殊需求，需要使用 TPM 增加你的工作站安全性。

## 预引导环境

这是你开始安装操作系统前的一系列推荐规范。

### 检查清单

- [ ] 使用 UEFI 引导模式（不是传统 BIOS）_(关键)_
- [ ] 进入 UEFI 配置需要使用密码 _(关键)_
- [ ] 使用安全引导 _(关键)_
- [ ] 启动系统需要 UEFI 级别密码 _(中等)_

### 注意事项

#### UEFI 和安全引导

UEFI 尽管有缺点，还是提供了很多传统 BIOS 没有的好功能，比如安全引导。大多数现代的系统都默认使用 UEFI 模式。

确保进入 UEFI 配置模式要使用高强度密码。注意，很多厂商默默地限制了你使用密码长度，所以相比长口令你也许应该选择高熵值的短密码（关于密码短语请参考下面内容）。

基于你选择的 Linux 发行版，你也许需要、也许不需要按照 UEFI 的要求，来导入你的发行版的安全引导密钥，从而允许你启动该发行版。很多发行版已经与微软合作，用大多数厂商所支持的密钥给它们已发布的内核签名，因此避免了你必须处理密钥导入的麻烦。

作为一个额外的措施，在允许某人访问引导分区然后尝试做一些不好的事之前，让他们输入密码。为了防止肩窥（shoulder-surfing），这个密码应该跟你的 UEFI 管理密码不同。如果你经常关闭和启动，你也许不想这么麻烦，因为你已经必须输入 LUKS 密码了（LUKS 参见下面内容），这样会让你您减少一些额外的键盘输入。

## 发行版选择注意事项

很有可能你会坚持一个广泛使用的发行版如 Fedora，Ubuntu，Arch，Debian，或它们的一个类似发行版。无论如何，以下是你选择使用发行版应该考虑的。

### 检查清单

- [ ] 拥有一个强健的 MAC/RBAC 系统（SELinux/AppArmor/Grsecurity） _(关键)_
- [ ] 发布安全公告 _(关键)_
- [ ] 提供及时的安全补丁 _(关键)_
- [ ] 提供软件包的加密验证 _(关键)_
- [ ] 完全支持 UEFI 和安全引导 _(关键)_
- [ ] 拥有健壮的原生全磁盘加密支持 _(关键)_

### 注意事项

#### SELinux，AppArmor，和 GrSecurity/PaX

强制访问控制（Mandatory Access Controls，MAC）或者基于角色的访问控制（Role-Based Access Controls，RBAC）是一个用在老式 POSIX 系统的基于用户或组的安全机制扩展。现在大多数发行版已经捆绑了 MAC/RBAC 系统（Fedora，Ubuntu），或通过提供一种机制一个可选的安装后步骤来添加它（Gentoo，Arch，Debian）。显然，强烈建议您选择一个预装 MAC/RBAC 系统的发行版，但是如果你对某个没有默认启用它的发行版情有独钟，装完系统后应计划配置安装它。

应该坚决避免使用不带任何 MAC/RBAC 机制的发行版，像传统的 POSIX 基于用户和组的安全在当今时代应该算是考虑不足。如果你想建立一个 MAC/RBAC 工作站，通常认为 AppArmor 和 PaX 比 SELinux 更容易掌握。此外，在工作站上，很少有或者根本没有对外监听的守护进程，而针对用户运行的应用造成的最高风险，GrSecurity/PaX _可能_ 会比SELinux 提供更多的安全便利。

#### 发行版安全公告

大多数广泛使用的发行版都有一个给它们的用户发送安全公告的机制，但是如果你对一些机密感兴趣，去看看开发人员是否有见于文档的提醒用户安全漏洞和补丁的机制。缺乏这样的机制是一个重要的警告信号，说明这个发行版不够成熟，不能被用作主要管理员的工作站。

#### 及时和可靠的安全更新

多数常用的发行版提供定期安全更新，但应该经常检查以确保及时提供关键包更新。因此应避免使用附属发行版（spin-offs）和“社区重构”，因为它们必须等待上游发行版先发布，它们经常延迟发布安全更新。

现在，很难找到一个不使用加密签名、更新元数据或二者都不使用的发行版。如此说来，常用的发行版在引入这个基本安全机制就已经知道这些很多年了（Arch，说你呢），所以这也是值得检查的。

#### 发行版支持 UEFI 和安全引导

检查发行版是否支持 UEFI 和安全引导。查明它是否需要导入额外的密钥或是否要求启动内核有一个已经被系统厂商信任的密钥签名（例如跟微软达成合作）。一些发行版不支持 UEFI 或安全启动，但是提供了替代品来确保防篡改（tamper-proof）或防破坏（tamper-evident）引导环境（[Qubes-OS][3] 使用 Anti Evil Maid，前面提到的）。如果一个发行版不支持安全引导，也没有防止引导级别攻击的机制，还是看看别的吧。

#### 全磁盘加密

全磁盘加密是保护静止数据的要求，大多数发行版都支持。作为一个选择方案，带有自加密硬盘的系统也可以用（通常通过主板 TPM 芯片实现），并提供了类似安全级别而且操作更快，但是花费也更高。

## 发行版安装指南

所有发行版都是不同的，但是也有一些一般原则：

### 检查清单

- [ ] 使用健壮的密码全磁盘加密（LUKS） _(关键)_
- [ ] 确保交换分区也加密了 _(关键)_
- [ ] 确保引导程序设置了密码（可以和LUKS一样） _(关键)_
- [ ] 设置健壮的 root 密码（可以和LUKS一样） _(关键)_
- [ ] 使用无特权账户登录，作为管理员组的一部分 _(关键)_
- [ ] 设置健壮的用户登录密码，不同于 root 密码 _(关键)_

### 注意事项

#### 全磁盘加密

除非你正在使用自加密硬盘，配置你的安装程序完整地加密所有存储你的数据与系统文件的磁盘很重要。简单地通过自动挂载的 cryptfs 环（loop）文件加密用户目录还不够（说你呢，旧版 Ubuntu），这并没有给系统二进制文件或交换分区提供保护，它可能包含大量的敏感数据。推荐的加密策略是加密 LVM 设备，以便在启动过程中只需要一个密码。

`/boot`分区将一直保持非加密，因为引导程序需要在调用 LUKS/dm-crypt 前能引导内核自身。一些发行版支持加密的`/boot`分区，比如 [Arch][16]，可能别的发行版也支持，但是似乎这样增加了系统更新的复杂度。如果你的发行版并没有原生支持加密`/boot`也不用太在意，内核镜像本身并没有什么隐私数据，它会通过安全引导的加密签名检查来防止被篡改。

#### 选择一个好密码

现代的 Linux 系统没有限制密码口令长度，所以唯一的限制是你的偏执和倔强。如果你要启动你的系统，你将大概至少要输入两个不同的密码：一个解锁 LUKS ，另一个登录，所以长密码将会使你老的更快。最好从丰富或混合的词汇中选择2-3个单词长度，容易输入的密码。

优秀密码例子（是的，你可以使用空格）：

- nature abhors roombas
- 12 in-flight Jebediahs
- perdon, tengo flatulence

如果你喜欢输入可以在公开场合和你生活中能见到的句子，比如：

- Mary had a little lamb
- you're a wizard, Harry
- to infinity and beyond

如果你愿意的话，你也应该带上最少要 10-12个字符长度的非词汇的密码。

除非你担心物理安全，你可以写下你的密码，并保存在一个远离你办公桌的安全的地方。

#### Root，用户密码和管理组

我们建议，你的 root 密码和你的 LUKS 加密使用同样的密码（除非你共享你的笔记本给信任的人，让他应该能解锁设备，但是不应该能成为 root 用户）。如果你是笔记本电脑的唯一用户，那么你的 root 密码与你的 LUKS 密码不同是没有安全优势上的意义的。通常，你可以使用同样的密码在你的 UEFI 管理，磁盘加密，和 root 登录中 -- 知道这些任意一个都会让攻击者完全控制您的系统，在单用户工作站上使这些密码不同，没有任何安全益处。

你应该有一个不同的，但同样强健的常规用户帐户密码用来日常工作。这个用户应该是管理组用户（例如`wheel`或者类似，根据发行版不同），允许你执行`sudo`来提升权限。

换句话说，如果在你的工作站只有你一个用户，你应该有两个独特的、强健（robust）而强壮（strong）的密码需要记住：

**管理级别**，用在以下方面：

- UEFI 管理
- 引导程序（GRUB）
- 磁盘加密（LUKS）
- 工作站管理（root 用户）

**用户级别**，用在以下：

- 用户登录和 sudo
- 密码管理器的主密码

很明显，如果有一个令人信服的理由的话，它们全都可以不同。

## 安装后的加固

安装后的安全加固在很大程度上取决于你选择的发行版，所以在一个像这样的通用文档中提供详细说明是徒劳的。然而,这里有一些你应该采取的步骤:

### 检查清单

- [ ] 在全局范围内禁用火线和雷电模块 _(关键)_
- [ ] 检查你的防火墙，确保过滤所有传入端口 _(关键)_
- [ ] 确保 root 邮件转发到一个你可以收到的账户 _(关键)_
- [ ] 建立一个系统自动更新任务，或更新提醒 _(中等)_
- [ ] 检查以确保 sshd 服务默认情况下是禁用的 _(中等)_
- [ ] 配置屏幕保护程序在一段时间的不活动后自动锁定 _(中等)_
- [ ] 设置 logwatch _(中等)_
- [ ] 安装使用 rkhunter _(中等)_
- [ ] 安装一个入侵检测系统（Intrusion Detection System） _(中等)_

### 注意事项

#### 将模块列入黑名单

将火线和雷电模块列入黑名单，增加一行到`/etc/modprobe.d/blacklist-dma.conf`文件：

    blacklist firewire-core
    blacklist thunderbolt

重启后的这些模块将被列入黑名单。这样做是无害的，即使你没有这些端口（但也不做任何事）。

#### Root 邮件

默认的 root 邮件只是存储在系统基本上没人读过。确保你设置了你的`/etc/aliases`来转发 root 邮件到你确实能读取的邮箱，否则你也许错过了重要的系统通知和报告：

    # Person who should get root's mail
    root:          bob@example.com

编辑后这些后运行`newaliases`，然后测试它确保能投递到，像一些邮件供应商将拒绝来自不存在的域名或者不可达的域名的邮件。如果是这个原因，你需要配置邮件转发直到确实可用。

#### 防火墙，sshd，和监听进程

默认的防火墙设置将取决于您的发行版，但是大多数都允许`sshd`端口连入。除非你有一个令人信服的合理理由允许连入 ssh，你应该过滤掉它，并禁用 sshd 守护进程。

    systemctl disable sshd.service
    systemctl stop sshd.service

如果你需要使用它，你也可以临时启动它。

通常，你的系统不应该有任何侦听端口，除了响应 ping 之外。这将有助于你对抗网络级的零日漏洞利用。

#### 自动更新或通知

建议打开自动更新，除非你有一个非常好的理由不这么做，如果担心自动更新将使您的系统无法使用（以前发生过，所以这种担心并非杞人忧天）。至少，你应该启用自动通知可用的更新。大多数发行版已经有这个服务自动运行，所以你不需要做任何事。查阅你的发行版文档了解更多。

你应该尽快应用所有明显的勘误，即使这些不是特别贴上“安全更新”或有关联的 CVE 编号。所有的问题都有潜在的安全漏洞和新的错误，比起停留在旧的、已知的问题上，未知问题通常是更安全的策略。

#### 监控日志

你应该会对你的系统上发生了什么很感兴趣。出于这个原因，你应该安装`logwatch`然后配置它每夜发送在你的系统上发生的任何事情的活动报告。这不会预防一个专业的攻击者，但是一个不错的安全网络功能。

注意，许多 systemd 发行版将不再自动安装一个“logwatch”所需的 syslog 服务（因为 systemd 会放到它自己的日志中），所以你需要安装和启用“rsyslog”来确保在使用 logwatch 之前你的 /var/log 不是空的。

#### Rkhunter 和 IDS

安装`rkhunter`和一个类似`aide`或者`tripwire`入侵检测系统（IDS）并不是那么有用，除非你确实理解它们如何工作，并采取必要的步骤来设置正确（例如，保证数据库在外部介质，从可信的环境运行检测，记住执行系统更新和配置更改后要刷新散列数据库，等等）。如果你不愿在你的工作站执行这些步骤，并调整你如何工作的方式，这些工具只能带来麻烦而没有任何实在的安全益处。

我们建议你安装`rkhunter`并每晚运行它。它相当易于学习和使用，虽然它不会阻止一个复杂的攻击者，它也能帮助你捕获你自己的错误。

## 个人工作站备份

工作站备份往往被忽视，或偶尔才做一次，这常常是不安全的方式。

### 检查清单

- [ ] 设置加密备份工作站到外部存储 _(关键)_
- [ ] 使用零认知（zero-knowledge）备份工具备份到站外或云上 _(中等)_

### 注意事项

#### 全加密的备份存到外部存储

把全部备份放到一个移动磁盘中比较方便，不用担心带宽和上行网速（在这个时代，大多数供应商仍然提供显著的不对称的上传/下载速度）。不用说，这个移动硬盘本身需要加密（再说一次，通过 LUKS），或者你应该使用一个备份工具建立加密备份，例如`duplicity`或者它的 GUI 版本 `deja-dup`。我建议使用后者并使用随机生成的密码，保存到离线的安全地方。如果你带上笔记本去旅行，把这个磁盘留在家，以防你的笔记本丢失或被窃时可以找回备份。

除了你的家目录外，你还应该备份`/etc`目录和出于取证目的的`/var/log`目录。

尤其重要的是，避免拷贝你的家目录到任何非加密存储上，即使是需要快速的在两个系统上移动文件时，一旦完成你肯定会忘了清除它，从而暴露个人隐私或者安全信息到监听者手中 -- 尤其是把这个存储介质跟你的笔记本放到同一个包里。

#### 有选择的零认知站外备份

站外备份（Off-site backup）也是相当重要的，是否可以做到要么需要你的老板提供空间，要么找一家云服务商。你可以建一个单独的 duplicity/deja-dup 配置，只包括重要的文件，以免传输大量你不想备份的数据（网络缓存、音乐、下载等等）。

作为选择，你可以使用零认知（zero-knowledge）备份工具，例如 [SpiderOak][5]，它提供一个卓越的 Linux GUI工具还有更多的实用特性，例如在多个系统或平台间同步内容。

## 最佳实践

下面是我们认为你应该采用的最佳实践列表。它当然不是非常详细的，而是试图提供实用的建议，来做到可行的整体安全性和可用性之间的平衡。

### 浏览

毫无疑问， web 浏览器将是你的系统上最大、最容易暴露的面临攻击的软件。它是专门下载和执行不可信、甚至是恶意代码的一个工具。它试图采用沙箱和代码清洁（code sanitization）等多种机制保护你免受这种危险，但是在之前它们都被击败了多次。你应该知道，在任何时候浏览网站都是你做的最不安全的活动。

有几种方法可以减少浏览器的影响，但这些真实有效的方法需要你明显改变操作您的工作站的方式。

#### 1: 使用两个不同的浏览器 _(关键)_

这很容易做到，但是只有很少的安全效益。并不是所有浏览器都可以让攻击者完全自由访问您的系统 -- 有时它们只能允许某人读取本地浏览器存储，窃取其它标签的活动会话，捕获浏览器的输入等。使用两个不同的浏览器，一个用在工作/高安全站点，另一个用在其它方面，有助于防止攻击者请求整个 cookie 存储的小问题。主要的不便是两个不同的浏览器会消耗大量内存。

我们建议：

##### 火狐用来访问工作和高安全站点

使用火狐登录工作有关的站点，应该额外关心的是确保数据如 cookies，会话，登录信息，击键等等，明显不应该落入攻击者手中。除了少数的几个网站，你不应该用这个浏览器访问其它网站。

你应该安装下面的火狐扩展：

- [ ] NoScript _(关键)_
  - NoScript 阻止活动内容加载，除非是在用户白名单里的域名。如果用于默认浏览器它会很麻烦（可是提供了真正好的安全效益），所以我们建议只在访问与工作相关的网站的浏览器上开启它。

- [ ] Privacy Badger _(关键)_
  - EFF 的 Privacy Badger 将在页面加载时阻止大多数外部追踪器和广告平台，有助于在这些追踪站点影响你的浏览器时避免跪了（追踪器和广告站点通常会成为攻击者的目标，因为它们能会迅速影响世界各地成千上万的系统）。

- [ ] HTTPS Everywhere _(关键)_
  - 这个 EFF 开发的扩展将确保你访问的大多数站点都使用安全连接，甚至你点击的连接使用的是 http://（可以有效的避免大多数的攻击，例如[SSL-strip][7]）。

- [ ] Certificate Patrol _(中等)_
  - 如果你正在访问的站点最近改变了它们的 TLS 证书，这个工具将会警告你 -- 特别是如果不是接近失效期或者现在使用不同的证书颁发机构。它有助于警告你是否有人正尝试中间人攻击你的连接，不过它会产生很多误报。

你应该让火狐成为你打开连接时的默认浏览器，因为 NoScript 将在加载或者执行时阻止大多数活动内容。

##### 其它一切都用 Chrome/Chromium

Chromium 开发者在增加很多很好的安全特性方面走在了火狐前面（至少[在 Linux 上][6]），例如 seccomp 沙箱，内核用户空间等等，这会成为一个你访问的网站与你其它系统之间的额外隔离层。Chromium 是上游开源项目，Chrome 是 Google 基于它构建的专有二进制包（加一句偏执的提醒，如果你有任何不想让谷歌知道的事情都不要使用它）。

推荐你在 Chrome 上也安装**Privacy Badger** 和 **HTTPS Everywhere** 扩展，然后给它一个与火狐不同的主题，以让它告诉你这是你的“不可信站点”浏览器。

#### 2: 使用两个不同浏览器，一个在专用的虚拟机里 _(中等)_

这有点像上面建议的做法，除了您将添加一个通过快速访问协议运行在专用虚拟机内部 Chrome 的额外步骤，它允许你共享剪贴板和转发声音事件（如，Spice 或 RDP）。这将在不可信浏览器和你其它的工作环境之间添加一个优秀的隔离层，确保攻击者完全危害你的浏览器将必须另外打破 VM 隔离层，才能达到系统的其余部分。

这是一个鲜为人知的可行方式，但是需要大量的 RAM 和高速的处理器来处理多增加的负载。这要求作为管理员的你需要相应地调整自己的工作实践而付出辛苦。

#### 3: 通过虚拟化完全隔离你的工作和娱乐环境 _(低等)_

了解下 [Qubes-OS 项目][3]，它致力于通过划分你的应用到完全隔离的 VM 中来提供高度安全的工作环境。

### 密码管理器

#### 检查清单

- [ ] 使用密码管理器 _(关键)_
- [ ] 不相关的站点使用不同的密码 _(关键)_
- [ ] 使用支持团队共享的密码管理器 _(中等)_
- [ ] 给非网站类账户使用一个单独的密码管理器 _(低等)_

#### 注意事项

使用好的、唯一的密码对你的团队成员来说应该是非常关键的需求。凭证（credential）盗取一直在发生 — 通过被攻破的计算机、盗取数据库备份、远程站点利用、以及任何其它的方式。凭证绝不应该跨站点重用，尤其是关键的应用。

##### 浏览器中的密码管理器

每个浏览器有一个比较安全的保存密码机制，可以同步到供应商维护的，并使用用户的密码保证数据加密。然而，这个机制有严重的劣势：

1. 不能跨浏览器工作
2. 不提供任何与团队成员共享凭证的方法

也有一些支持良好、免费或便宜的密码管理器，可以很好的融合到多个浏览器，跨平台工作，提供小组共享（通常是付费服务）。可以很容易地通过搜索引擎找到解决方案。

##### 独立的密码管理器

任何与浏览器结合的密码管理器都有一个主要的缺点，它实际上是应用的一部分，这样最有可能被入侵者攻击。如果这让你不放心（应该这样），你应该选择两个不同的密码管理器 -- 一个集成在浏览器中用来保存网站密码，一个作为独立运行的应用。后者可用于存储高风险凭证如 root 密码、数据库密码、其它 shell 账户凭证等。

这样的工具在团队成员间共享超级用户的凭据方面特别有用（服务器 root 密码、ILO密码、数据库管理密码、引导程序密码等等）。

这几个工具可以帮助你：

- [KeePassX][8]，在第2版中改进了团队共享
- [Pass][9]，它使用了文本文件和 PGP，并与 git 结合
- [Django-Pstore][10]，它使用 GPG 在管理员之间共享凭据
- [Hiera-Eyaml][11]，如果你已经在你的平台中使用了 Puppet，在你的 Hiera 加密数据的一部分里面，可以便捷的追踪你的服务器/服务凭证。

### 加固 SSH 与 PGP 的私钥

个人加密密钥，包括 SSH 和 PGP 私钥，都是你工作站中最重要的物品 -- 这是攻击者最想得到的东西，这可以让他们进一步攻击你的平台或在其它管理员面前冒充你。你应该采取额外的步骤，确保你的私钥免遭盗窃。

#### 检查清单

- [ ] 用来保护私钥的强壮密码 _(关键)_
- [ ] PGP 的主密码保存在移动存储中 _(中等)_
- [ ] 用于身份验证、签名和加密的子密码存储在智能卡设备 _(中等)_
- [ ] SSH 配置为以 PGP 认证密钥作为 ssh 私钥 _(中等)_

#### 注意事项

防止私钥被偷的最好方式是使用一个智能卡存储你的加密私钥，绝不要拷贝到工作站上。有几个厂商提供支持 OpenPGP 的设备：

- [Kernel Concepts][12]，在这里可以采购支持 OpenPGP 的智能卡和 USB 读取器，你应该需要一个。
- [Yubikey NEO][13]，这里提供 OpenPGP 功能的智能卡还提供很多很酷的特性（U2F、PIV、HOTP等等）。 

确保 PGP 主密码没有存储在工作站也很重要，仅使用子密码。主密钥只有在签名其它的密钥和创建新的子密钥时使用 — 不经常发生这种操作。你可以照着 [Debian 的子密钥][14]向导来学习如何将你的主密钥移动到移动存储并创建子密钥。

你应该配置你的 gnupg 代理作为 ssh 代理，然后使用基于智能卡 PGP 认证密钥作为你的 ssh 私钥。我们发布了一个[详尽的指导][15]如何使用智能卡读取器或 Yubikey NEO。

如果你不想那么麻烦，最少要确保你的 PGP 私钥和你的 SSH 私钥有个强健的密码，这将让攻击者很难盗取使用它们。

### 休眠或关机，不要挂起

当系统挂起时，内存中的内容仍然保留在内存芯片中，可以会攻击者读取到（这叫做冷启动攻击（Cold Boot Attack））。如果你离开你的系统的时间较长，比如每天下班结束，最好关机或者休眠，而不是挂起它或者就那么开着。

### 工作站上的 SELinux

如果你使用捆绑了 SELinux 的发行版（如 Fedora），这有些如何使用它的建议，让你的工作站达到最大限度的安全。

#### 检查清单

- [ ] 确保你的工作站强制（enforcing）使用 SELinux _(关键)_
- [ ] 不要盲目的执行`audit2allow -M`，应该经常检查  _(关键)_
- [ ] 绝不要 `setenforce 0` _(中等)_
- [ ] 切换你的用户到 SELinux 用户`staff_u` _(中等)_

#### 注意事项

SELinux 是强制访问控制（Mandatory Access Controls，MAC），是 POSIX许可核心功能的扩展。它是成熟、强健，自从它推出以来已经有很长的路了。不管怎样，许多系统管理员现在仍旧重复过时的口头禅“关掉它就行”。

话虽如此，在工作站上 SELinux 会带来一些有限的安全效益，因为大多数你想运行的应用都是可以自由运行的。开启它有益于给网络提供足够的保护，也有可能有助于防止攻击者通过脆弱的后台服务提升到 root 级别的权限用户。

我们的建议是开启它并强制使用（enforcing）。

##### 绝不`setenforce 0`

使用`setenforce 0`临时把 SELinux 设置为许可（permissive）模式很有诱惑力，但是你应该避免这样做。当你想查找一个特定应用或者程序的问题时，实际上这样做是把整个系统的 SELinux 给关闭了。

你应该使用`semanage permissive -a [somedomain_t]`替换`setenforce 0`，只把这个程序放入许可模式。首先运行`ausearch`查看哪个程序发生问题：

    ausearch -ts recent -m avc

然后看下`scontext=`（源自 SELinux 的上下文）行，像这样：

    scontext=staff_u:staff_r:gpg_pinentry_t:s0-s0:c0.c1023
                             ^^^^^^^^^^^^^^

这告诉你程序`gpg_pinentry_t`被拒绝了，所以你想排查应用的故障，应该增加它到许可域：

    semange permissive -a gpg_pinentry_t

这将允许你使用应用然后收集 AVC 的其它数据，你可以结合`audit2allow`来写一个本地策略。一旦完成你就不会看到新的 AVC 的拒绝消息，你就可以通过运行以下命令从许可中删除程序：

    semanage permissive -d gpg_pinentry_t

##### 用 SELinux 的用户 staff_r 使用你的工作站

SELinux 带有角色（role）的原生实现，基于用户帐户相关角色来禁止或授予某些特权。作为一个管理员，你应该使用`staff_r`角色，这可以限制访问很多配置和其它安全敏感文件，除非你先执行`sudo`。

默认情况下，用户以`unconfined_r`创建，你可以自由运行大多数应用，没有任何（或只有一点）SELinux 约束。转换你的用户到`staff_r`角色，运行下面的命令：

    usermod -Z staff_u [username]

你应该退出然后登录新的角色，届时如果你运行`id -Z`，你将会看到：

    staff_u:staff_r:staff_t:s0-s0:c0.c1023

在执行`sudo`时，你应该记住增加一个额外标志告诉 SELinux 转换到“sysadmin”角色。你需要用的命令是：

    sudo -i -r sysadm_r

然后`id -Z`将会显示：

    staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

**警告**：在进行这个切换前你应该能很顺畅的使用`ausearch`和`audit2allow`，当你以`staff_r`角色运行时你的应用有可能不再工作了。在写作本文时，已知以下流行的应用在`staff_r`下没有做策略调整就不会工作：

- Chrome/Chromium
- Skype
- VirtualBox

切换回`unconfined_r`，运行下面的命令：

    usermod -Z unconfined_u [username]

然后注销再重新回到舒适区。

## 延伸阅读

IT 安全的世界是一个没有底的兔子洞。如果你想深入，或者找到你的具体发行版更多的安全特性，请查看下面这些链接：

- [Fedora 安全指南](https://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/index.html)
- [CESG Ubuntu 安全指南](https://www.gov.uk/government/publications/end-user-devices-security-guidance-ubuntu-1404-lts)
- [Debian 安全手册](https://www.debian.org/doc/manuals/securing-debian-howto/index.en.html)
- [Arch Linux 安全维基](https://wiki.archlinux.org/index.php/Security)
- [Mac OSX 安全](https://www.apple.com/support/security/guides/)

## 许可

这项工作在[创作共用授权4.0国际许可证][0]许可下。

--------------------------------------------------------------------------------

via: https://github.com/lfit/itpol/blob/bbc17d8c69cb8eee07ec41f8fbf8ba32fdb4301b/linux-workstation-security.md

作者：[mricon][a]
译者：[wyangsun](https://github.com/wyangsun)
校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]:https://github.com/mricon
[0]: http://creativecommons.org/licenses/by-sa/4.0/
[1]: https://github.com/QubesOS/qubes-antievilmaid
[2]: https://en.wikipedia.org/wiki/IEEE_1394#Security_issues
[3]: https://qubes-os.org/
[4]: https://xkcd.com/936/
[5]: https://spideroak.com/
[6]: https://code.google.com/p/chromium/wiki/LinuxSandboxing
[7]: http://www.thoughtcrime.org/software/sslstrip/
[8]: https://keepassx.org/
[9]: http://www.passwordstore.org/
[10]: https://pypi.python.org/pypi/django-pstore
[11]: https://github.com/TomPoulton/hiera-eyaml
[12]: http://shop.kernelconcepts.de/
[13]: https://www.yubico.com/products/yubikey-hardware/yubikey-neo/
[14]: https://wiki.debian.org/Subkeys
[15]: https://github.com/lfit/ssh-gpg-smartcard-config
[16]: http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
[17]: https://en.wikipedia.org/wiki/Cold_boot_attack
[18]: http://www.linux.com/news/featured-blogs/167-amanda-mcpherson/850607-linux-foundation-sysadmins-open-source-their-it-policies