如今，加强服务器的安全性比以往任何时候都更加重要，但如果您查看一些官方的安全加固指南，它们读起来就像是为 2005 年的 Red Hat 编写的一样。那是因为它们确实是为 2005 年的 Red Hat 编写的，并在这些年中这里那里地进行了更新。我在参考 PCI 审计的一些官方安全加固基准时，偶然发现了其中一份指南，并意识到如果 Linux 服务器管理新手遇到相同的指南，他们可能会被所有晦涩的步骤搞得不知所措。更糟糕的是，他们可能会花费数小时进行晦涩的 sysctl 调整，最终却得到一台对现代攻击毫无防御能力的计算机。相反，他们本可以花几分钟执行一些简单的安全加固步骤，并在最后得到一台更安全的计算机。因此，在本文中，我将介绍一些安全加固步骤，这些步骤能够以最小的代价获得最大的收益。这些技巧应该只需要几分钟，但通过这些努力，您最终应该获得一个更加安全的系统。

在谈论一些安全加固建议之前，我想先强调一下您可能在那些较旧的安全加固指南中看到的一些经典安全步骤。现在，这并不是说所有这些步骤都是不好的建议，只是在许多情况下，这些建议指的是已弃用的系统，或者描述的是现代 Linux 服务器发行版多年来默认采取的步骤。

例如，许多安全加固指南花费大量时间关注 tcpwrappers，这是一种经典的 Linux 服务，可让您限制哪些 IP 可以访问特定服务。如今，大多数管理员使用 iptables 防火墙规则来限制对端口的访问。您还会被建议启用影子密码，并禁用常用角色帐户（如 mail、bind、www 和 mysql 用户）的 shell。虽然这不是坏建议，但事实是，所有 Linux 发行版都已经为您开箱即用地完成了这一点。

您通常会在安全加固指南中看到的另一个技巧是禁用所有不必要的服务，特别是，指南会告诉您禁用 telnet、daytime、chargen 和许多其他晦涩的 inetd 服务，这些服务不仅长期以来默认情况下未启用，而且在许多情况下，它们甚至不再默认安装。事实是，大多数服务器发行版在出厂时都关闭了除 SSH 之外的所有网络服务。说到 SSH，既然我已经谈到了一些经典的安全加固技巧，那么让我讨论一些现代安全加固技巧，首先从 SSH 开始。

正如我所提到的，您将遇到的几乎每台服务器都默认启用 SSH，并且假设您将使用它进行远程管理。以下是对您的 /etc/ssh/sshd_config 文件进行的一些简单更改，这些更改只需几秒钟，但可以使其更安全。

首先，禁用 root 登录，并确保您仅使用 SSH 协议 2（以前的协议存在已知漏洞）。在许多发行版（特别是许多云镜像）中，可能已经为您完成了这些步骤

PermitRootLogin no
Protocol 2

在我看来，当人们谈论服务器安全加固时，很多人过于关注 SSH 暴力破解攻击。诚然，如果您将 Linux 服务器放在互联网上，您将在日志中看到的第一件事就是持续不断的 SSH 暴力破解尝试。许多系统管理员会采取一些我认为介于无效、荒谬和过度的措施，包括将 SSH 移动到一些随机端口（隐蔽式安全）或使用像 fail2ban 这样的系统。使用 fail2ban，您的系统会读取失败的登录尝试，并创建防火墙规则以在几次失败的尝试后阻止攻击者。这表面上看起来很明智，但它存在一些问题

1. 这只会阻止拥有一台机器的攻击者——大多数攻击者都拥有僵尸网络，并将暴力破解攻击分散到多个 IP 地址。

2. 如果您有一个弱的、容易猜到的密码和一个常用的用户名，他们可能会在 fail2ban 生效之前猜到密码。

3. 让攻击者执行自动更新系统防火墙规则的操作是危险的。

4. 通常内部网络会被列入白名单——攻击者仍然可以从您网络上不同的受感染机器对您进行暴力破解攻击。

与其采取所有这些步骤来缓解 SSH 暴力破解攻击，我建议您完全消除这种攻击：禁用密码身份验证，仅依赖 SSH 密钥。在您启用此选项之前，请确保每个登录到此机器的人（或至少是管理员）都已生成并测试了使用 SSH 密钥登录——您不希望被锁定在外。当您准备好后，将 sshd_config 中的 PasswordAuthentication 参数更改为

PasswordAuthentication no

最后一个快速的 SSH 安全加固步骤是限制要使用的密码套件和算法，以便您仅使用当今标准认为安全的那些。我不是密码学家，但我不需要成为密码学家就可以查看密码学家的建议，并将它们复制粘贴到我的 SSH 配置中

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,
  aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

KexAlgorithms curve25519-sha256@libssh.org,
↪diffie-hellman-group-exchange-sha256

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,
  hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,
↪hmac-sha2-512,
  hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

所有这些设置都就位后，重新启动 SSH 服务以使用它们。

对于系统帐户的通用安全加固，我能给出的最佳建议是完全禁用 root 帐户，并且仅使用 sudo。您还应该避免直接登录任何共享帐户，无论是 root 帐户还是像管理您的应用程序或 Web 服务器的用户这样的角色帐户。通过要求用户以自己的身份登录，然后 sudo 提升为 root 或角色帐户，您可以为谁做了什么提供良好的审计跟踪，并且当用户不再需要帐户时，您可以更轻松地撤销访问权限——由于共享帐户没有密码，因此您不必在每次团队成员离开时都更改密码；相反，您只需删除该用户的帐户即可。

大多数发行版目前都包含 sudo，有些发行版还在默认情况下禁用 root 帐户，或者允许您在安装期间禁用它。否则，您可以简单地编辑您的 /etc/shadow 文件，并将您为 root 用户设置的任何密码替换为 * 符号。只需确保您首先让 sudo 与至少一个帐户一起工作，这样您就不会将自己锁定在外。

使用 sudo 时，您应该遵循一些做法来帮助保持其安全。首先，虽然对于可能运行 cron 作业（如备份作业）的守护程序来说，使用 NOPASSWD sudo 规则（不需要您输入密码的规则）在某种程度上是不可避免的，但您应该将任何 NOPASSWD sudo 规则限制为仅适用于这些守护程序角色帐户，并要求所有真实用户输入密码。尽可能地，您还应该遵循最小权限原则，并且仅授予用户 sudo 访问权限，以访问他们需要的特定命令，而不是授予他们以特定用户（尤其是 root 用户）身份运行所有命令的访问权限。最后，如果您发现自己授予用户访问通用命令的权限来执行某些特定操作（例如，授予他们访问 service 或 systemctl 的权限，以便他们可以仅重启一项服务），请考虑创建一个简单的 shell 脚本，该脚本仅使用您想要的特定参数运行命令，并授予他们对该脚本的 sudo 访问权限。

虽然这些安全加固步骤不是您应该为锁定服务器而做的唯一事情，但它们是一个良好的开端，应该只需要几分钟。在我的下一篇文章中，我将添加另一轮简单的安全加固技巧，包括 SSH 客户端安全加固和云安全加固步骤，最后我将给出一些通用建议。