整理服务器的时候，我重新读了一遍 How To Secure A Linux Server。它不是一份“执行完就安全”的脚本，而是一份持续维护的 Linux 加固手册：从威胁模型开始，依次讨论 SSH、权限、网络、更新和审计。仓库最近一次更新在 2026 年 7 月，内容仍在演进；其中不少命令偏向 Debian 系，但它最值得借走的其实是做事的顺序。
安全这件事很容易被想成一个工具列表：装个防火墙、装个 Fail2Ban、改几个 SSH 选项。但真正麻烦的通常不是“不知道要装什么”，而是改动之间会互相影响。把密码登录关掉之前，密钥有没有真的可用？把出站流量全拒绝之后，系统更新、DNS 和时间同步会不会一起断掉？一台机器是否安全，首先取决于我们有没有清楚地知道它在对外提供什么。
先写下自己在防什么
这份仓库开头没有直接给命令，而是先问 threat model：机器暴露在哪里、谁需要访问、丢了什么最难受、能接受多少使用上的麻烦。这一步有点朴素，但很重要。
一台只通过 Tailscale 访问的个人 VPS，和一台公开提供 HTTPS 服务的博客机，策略显然不同；家里的 NAS、CI runner 和实验室 GPU 节点，也不该套同一份模板。安全并不是把限制开到最大，而是让每一项开放都有清楚的理由。
一个很实用的起点：列出“谁通过什么方式访问这台机器”和“这台机器需要对外提供哪些端口”。列不出来的服务，往往就是该继续确认的服务。
最先保护的，是别把自己锁在门外
对远程 Linux 服务器来说，SSH 是管理入口，也是最需要谨慎动手的部分。仓库建议使用公私钥、禁止 root 直接登录、限制可 SSH 的用户或用户组，并给认证尝试、空闲会话等设置合理边界。这些方向没有什么花哨的，真正重要的是分步切换。
我的习惯是：先在第二个终端确认密钥登录可用，再考虑禁用密码；修改 sshd_config 后，先用 sshd -t 检查语法，再 reload；旧会话始终留着，直到新连接完全验证通过。这样即使少了一个配置项，也不至于在半夜和云厂商救援控制台面面相觑。
# 改配置前先确认当前有效配置和监听端口
sudo sshd -T
sudo ss -lntup
# 修改后先做语法检查；通过后再应用
sudo sshd -t
sudo systemctl reload ssh仓库还收录了 MFA、SSH 转发限制、允许组、强密码策略等更细的项目。它们都值得评估，但不建议把一份完整示例配置原封不动粘进自己的机器。OpenSSH 版本、是否依赖端口转发、自动化账号怎样登录，都会改变“正确配置”的答案。
防火墙的重点不是“有”，而是“只放行需要的”
网络部分的中心思想是 default deny：入站默认拒绝，只为明确服务开口。对大多数小服务器，这比记住一大串危险端口更可靠。用 UFW 还是 nftables 不那么关键，关键是规则能被人读懂、服务变更后能被复查。
这里有一个很容易被忽略的取舍：仓库连出站流量也建议默认拒绝。这在高敏感场景下很合理，但会让 DNS、NTP、软件包更新、邮件告警和容器拉取都需要显式放行。对于普通博客或个人 VPS，我更倾向于先收紧入站，等明确知道服务的出站依赖后，再逐步约束出站；否则“防火墙启用了”也可能只是让维护能力悄悄失效。
# 先看清机器现在到底监听了什么
sudo ss -lntup
# UFW 使用前，先保留现有 SSH 会话，并只放行真正需要的服务
sudo ufw status verbose更新不是背景任务，是运行策略
仓库专门讨论了 unattended upgrades 和更新通知。它提醒了一个常识：已知漏洞的修复窗口，往往比某个精巧的 SSH 参数更重要。但“自动更新”也不是应该不假思索打开的开关，特别是承载生产服务或特殊驱动的机器。
比较稳妥的做法是先保证系统处于仍受支持的发行版版本，然后决定安全更新要自动安装，还是只自动通知、由维护窗口处理。无论哪种，都需要确认更新日志看得到、重启需求会被发现、出问题后有可用恢复路径。没人盯着的自动化，最后只会变成一种更安静的未知状态。
Fail2Ban、日志和审计：让异常留下痕迹
防火墙决定哪些门能被敲，Fail2Ban 这类工具则根据应用日志处理反复敲门的人。对于暴露在公网的 SSH 或 Web 服务，它是很实用的附加层：从日志里识别持续失败的认证，再临时封禁对应来源。前提是日志路径正确、规则确实命中了自己的服务，并且你知道怎样查看和解除误封。
更基础的一层是观察。仓库推荐用 ss 定期查看监听端口，用 logwatch 汇总日志，用 Lynis 做主机安全审计。这里我很赞同：安全工具的输出不必每天逐行读，但应该有一个节奏，把“系统现在和上个月有什么不同”变成可回答的问题。
# 看端口与进程归属
sudo ss -lntup
# 看 Fail2Ban 的 jail 和 SSH 状态（已安装时）
sudo fail2ban-client status
sudo fail2ban-client status sshd
# 用 Lynis 做一次基线扫描（已安装时）
sudo lynis audit system一份适合逐项推进的清单
- 确认发行版仍在支持期，安装必要的安全更新。
- 盘点本机账户、sudo 权限、SSH 登录方式和实际监听端口。
- 在保留可用会话的前提下，完成密钥登录和 root 登录限制。
- 让入站规则默认收紧，只为 SSH、HTTP/HTTPS 或确有需要的服务开口。
- 为公网暴露的认证入口配置速率限制或 Fail2Ban，并测试误封时的处理路径。
- 建立更新、日志和周期审计的节奏；服务一变，重新看端口与权限。
结语
How To Secure A Linux Server 的价值不是替人做完加固，而是把“零散的安全常识”按依赖关系排好了：先明确边界，再保住入口，再收窄暴露面，最后让变化可见。它也诚实地标记了仍在完善的部分，这比一份假装万能的“终极脚本”可靠得多。
我会把它当作一个很好的检查框架，而不是复制粘贴的配置来源。具体选项仍然应该以自己的发行版文档、当前 OpenSSH 版本和服务依赖为准。安全配置的完成标志，也不是命令执行成功，而是你仍然能正常维护机器，并且知道它正在做什么。
原始仓库：imthenachoman/How-To-Secure-A-Linux-Server。仓库也链接了 CIS Benchmarks 等更严格、面向合规的基线；有明确合规要求的环境，应该优先采用相应发行版的正式标准。
评论