[Brave]

Brave

LinuxSecurity 创始人 Dave Wreski 指出：“近年来针对 Linux 系统的攻击急剧增加，现在绝对不是在系统安全和维护方面松懈的时候。绝大多数针对 Linux 系统的成功攻击，并不能归咎于操作系统本身，而应归因于服务器配置不当和系统管理疏忽。”

这句话深刻揭示了服务器安全的本质：安全不是产品，而是过程。本课程将带你建立一套完整的安全防护体系。

---

一、访问控制与身份验证

访问控制是服务器安全的第一道防线。攻击者最常见的入侵途径就是通过暴力破解密码或利用弱认证机制获取系统访问权限。

1.1 禁用密码登录，强制使用 SSH 密钥对

为什么密码登录不安全？

传统密码登录面临以下威胁：

• 暴力破解攻击：攻击者可使用自动化工具每秒尝试数百次密码组合
• 字典攻击：使用常见密码列表进行批量尝试
• 凭证泄露：密码可能通过钓鱼、社会工程或其他系统的数据泄露而暴露

SSH 密钥对的工作原理

SSH 密钥对基于非对称加密技术，由两部分组成：

密钥类型	存储位置	安全要求
🔑 私钥 (Private Key)	你的本地电脑 ~/.ssh/id_ed25519	绝对不能泄露，建议设置密码保护
🔓 公钥 (Public Key)	服务器 ~/.ssh/authorized_keys	可公开分享，无安全风险

验证流程：

1. 客户端发起连接请求
2. 服务器发送一段随机”挑战信息”
3. 客户端使用私钥对挑战信息进行签名
4. 服务器使用公钥验证签名的有效性
5. 验证通过则允许登录

操作步骤

第一步：在本地电脑生成密钥对

bash

ssh-keygen -t ed25519 -C "your_email@example.com" 

💡 算法选择说明：Ed25519 是 2026 年推荐的首选加密算法，相比传统 RSA 具有以下优势：

• 密钥长度更短（仅 256 位），但安全性等同于 RSA-3072
• 签名和验证速度更快
• 抗侧信道攻击能力更强
• 不建议使用 RSA-2048 或更短的密钥，RSA-4096 仍可接受但已不推荐

生成过程中会提示设置 Passphrase（密钥口令）。强烈建议设置——这样即使你的电脑被盗或私钥文件被窃取，攻击者没有口令也无法使用你的私钥。

第二步：将公钥上传到服务器

ssh-copy-id -p 端口号 用户名@服务器IP

如果你使用 Windows 且没有 ssh-copy-id 命令，可以手动操作：

1. 打开本地 ~/.ssh/id_ed25519.pub 文件
2. 复制其中的全部内容
3. 粘贴到服务器的 ~/.ssh/authorized_keys 文件中（每个公钥占一行）

第三步：禁用服务器的密码登录

⚠️ 警告：在确保密钥登录成功测试通过前，请勿执行此步骤！建议保持一个已登录的 SSH 会话不要关闭，以防配置错误导致无法登录。

编辑 SSH 配置文件：

sudo nano /etc/ssh/sshd_config

找到并修改以下配置项：

PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

重启 SSH 服务使配置生效：

sudo systemctl restart ssh   # Debian/Ubuntu sudo systemctl restart sshd  # RHEL/CentOS/Fedora

1.2 禁用 Root 直接登录

Root 用户拥有系统的最高权限，如果攻击者获取了 Root 访问权限，后果将是灾难性的。禁止 Root 直接 SSH 登录可以：

• 增加攻击者的入侵难度（需要先获取普通用户权限，再进行提权）
• 提供审计追踪能力（可以记录是哪个用户执行了 sudo 操作）
• 符合最小权限原则

配置方法

在 /etc/ssh/sshd_config 中设置：

PermitRootLogin no

日常操作流程应为：

1. 使用普通用户 SSH 登录服务器
2. 需要执行高权限操作时使用 sudo 命令
3. 避免使用 sudo su - 长时间保持 root 身份

1.3 更改默认 SSH 端口

将 SSH 默认端口（22）修改为 1024 以上的随机端口，可以有效规避大规模自动化扫描工具。这是一种”隐蔽安全”(Security through Obscurity) 策略，虽然不能阻止针对性攻击，但能显著减少日志中的噪音和自动化攻击尝试。

配置方法

在 /etc/ssh/sshd_config 中修改：

Port 52222  # 选择 1024-65535 之间的随机端口

📊 实际效果：根据安全研究统计，将 SSH 端口从 22 改为非标准端口后，自动化扫描尝试可减少 90% 以上。

1.4 启用多因素认证 (MFA)

多因素认证在密码或密钥之外增加了额外的安全层，即使私钥被盗，攻击者没有你的第二因素（如手机）也无法登录。

方案一：Google Authenticator (TOTP)

安装 PAM 模块：

sudo apt install libpam-google-authenticator  # Debian/Ubuntu sudo dnf install google-authenticator          # RHEL/Fedora

为用户配置：

google-authenticator

按照提示完成设置，然后修改 PAM 配置：

sudo nano /etc/pam.d/sshd

添加：

auth required pam_google_authenticator.so

方案二：硬件安全密钥 (FIDO2/U2F) —— 2026 年最强方案

硬件安全密钥（如 YubiKey）将私钥存储在专用硬件中，具有以下优势：

• 私钥无法被复制或导出
• 登录时必须物理触摸硬件
• 可选要求输入 PIN 码进行双重验证

生成 FIDO2 密钥：

ssh-keygen -t ed25519-sk -O resident -O verify-required -C "yubikey-server-key" 

参数说明：

• -t ed25519-sk：使用 Ed25519 算法的安全密钥版本
• -O resident：密钥存储在 YubiKey 内部，可在不同电脑间使用
• -O verify-required：每次使用都需要输入 PIN 并触摸硬件

⚠️ 防止锁定的关键措施：

1. 注册备用密钥：将两把 YubiKey 都注册到 authorized_keys 中
2. 保留传统密钥：在过渡期保留一个普通 SSH 密钥作为后路
3. 确保控制台访问：确保你拥有服务器的控制台访问权限（如云服务商的网页 VNC 或物理机的显示器）

1.5 身份验证代理与零信任方案

传统 VPN 与零信任的对比：

根据 Tailscale 2025 年零信任报告，在接受调查的 1000 名 IT 和安全领导者中：

• 41% 仍在使用传统 VPN，但约 90% 报告遇到明显问题
• 27% 已采用点对点网格 VPN（如 Tailscale）
• 34% 使用云交付的 ZTNA 平台
• 83% 的受访者承认曾绕过安全措施来完成工作

Tailscale SSH 的零信任特性：

• 基于身份提供商（如 GitHub、Google、Okta）进行身份验证
• 无需手动管理繁琐的密钥文件
• 支持细粒度的 ACL 权限控制
• 会话录制功能：可记录 SSH 会话内容用于合规审计
• Check Mode：对高风险连接（如 root 用户）要求重新认证

---

二、网络防御

网络层的安全配置是防止外部攻击的第二道防线。合理的防火墙规则和入侵防护机制可以将大多数攻击阻挡在门外。

2.1 配置防火墙

核心原则：”默认拒绝” (Default Deny)

防火墙应配置为默认拒绝所有入站连接，仅开放必要的服务端口。

Ubuntu/Debian 使用 UFW：

# 启用 UFW sudo ufw default deny incoming
sudo ufw default allow outgoing

# 开放必要端口 sudo ufw allow 52222/tcp  # SSH（使用你的自定义端口） sudo ufw allow 80/tcp     # HTTP sudo ufw allow 443/tcp    # HTTPS 
# 启用防火墙 sudo ufw enable 
# 查看规则状态 sudo ufw status verbose

RHEL/CentOS/Fedora 使用 Firewalld：

# 启动并启用 firewalld sudo systemctl start firewalld
sudo systemctl enable firewalld

# 添加允许的服务 sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-port=52222/tcp

# 重新加载配置 sudo firewall-cmd --reload

2026 年推荐的模块化方案：UFW + IPSet + Fail2Ban

根据 最新安全实践，这种模块化组合被认为是 2025-2026 年 Linux 安全最佳实践：

• UFW：提供基础防火墙规则管理
• IPSet：高效管理大量 IP 地址集合
• Fail2Ban：动态封禁恶意 IP

模块化优势：如果 Fail2Ban 配置出错，底层的 UFW 防火墙仍在运行保护你的端口；而像 CSF 这样的单体解决方案，一旦配置出错可能导致整个防护失效。

2.2 安装 Fail2Ban

Fail2Ban 通过监控系统日志，自动封禁多次尝试登录失败的 IP 地址。

安装：

sudo apt install fail2ban  # Debian/Ubuntu sudo dnf install fail2ban  # RHEL/Fedora

创建本地配置文件：

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

推荐配置：

[DEFAULT] bantime = 1h          # 封禁时长 findtime = 10m        # 检测时间窗口 maxretry = 5          # 最大失败次数 
[sshd] enabled = true port = 52222          # 使用你的自定义 SSH 端口 filter = sshd
logpath = /var/log/auth.log
maxretry = 3          # SSH 可以设置更严格的阈值 bantime = 24h         # SSH 封禁时间可以更长 

启动服务：

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# 查看封禁状态 sudo fail2ban-client status sshd

关键调优参数：

参数	说明	建议值
bantime	封禁持续时间	对嘈杂攻击者设置为数天；对机构用户设置较短以减少误伤
findtime	计算失败次数的时间窗口	小窗口捕获爆发式攻击；大窗口捕获缓慢持续攻击
maxretry	触发封禁的失败次数	值越低越严格，但可能产生误报

Fail2Ban 的替代方案

根据 2025 年替代方案分析：

工具	特点	适用场景
CrowdSec	开源免费，使用机器学习分析日志，支持社区协作防御	需要高级威胁检测的环境
SSHGuard	轻量级，专注于 SSH 保护	只需保护 SSH 的简单场景
OSSEC	全面的主机入侵检测系统 (HIDS)，实时监控和响应	企业级安全需求
DenyHosts	轻量级，自动将恶意 IP 添加到 hosts.deny	资源受限环境

2.3 关闭闲置端口

定期检查并关闭不必要的网络服务，减少攻击面。

查看当前监听端口：

bash

ss -tunlp
# 或 netstat -tunlp

输出示例解读：

 

Netid  State   Local Address:Port   Process
tcp    LISTEN  0.0.0.0:22           sshd
tcp    LISTEN  0.0.0.0:80           nginx
tcp    LISTEN  127.0.0.1:3306       mysql

关注点：

• 监听在 0.0.0.0 的服务对外部可访问
• 监听在 127.0.0.1 的服务仅本地可访问
• 任何你不认识或不需要的服务都应该关闭或限制

2.4 限制来源 IP（IP 白名单）

如果你的访问 IP 是固定的，这是最有效的防护措施之一。

使用 UFW：

sudo ufw allow from 你的固定IP to any port 52222
sudo ufw deny 52222  # 拒绝其他所有 IP 访问 SSH 端口 

使用 /etc/hosts.allow 和 /etc/hosts.deny：

# /etc/hosts.allow sshd: 你的固定IP, 另一个IP
# /etc/hosts.deny sshd: ALL

---

三、系统维护与监控

安全不是一次性配置完成的任务，而是需要持续维护的过程。及时的安全补丁更新和持续的系统监控是防止已知漏洞被利用的关键。

3.1 自动安全更新 (Unattended Upgrades)

为什么自动更新至关重要？

根据 CIQ 的 2025 年 Linux 内核 CVE 报告，2025 年已报告的 Linux 内核漏洞数量达到 5530 个，相比 2024 年的 4329 个增加了 1201 个。这一数字的急剧增长源于 Linux 内核团队在 2024 年成为 CVE 编号机构后，漏洞披露率大幅加速。

这意味着：手动跟踪和安装补丁已经不现实，自动化是必须的。

Ubuntu/Debian 配置：

sudo apt install unattended-upgrades apt-listchanges

sudo dpkg-reconfigure unattended-upgrades

编辑配置文件 /etc/apt/apt.conf.d/50unattended-upgrades：

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};

Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// 可选：自动重启（谨慎使用）
// Unattended-Upgrade::Automatic-Reboot "true";
// Unattended-Upgrade::Automatic-Reboot-Time "03:00";

RHEL/CentOS/Fedora 配置：

sudo dnf install dnf-automatic

sudo systemctl enable dnf-automatic.timer
sudo systemctl start dnf-automatic.timer

内核实时补丁（减少重启）

2026 年的最佳实践是使用内核实时补丁技术，在不重启的情况下应用关键安全更新：

• Ubuntu：Canonical Livepatch
• RHEL：kpatch
• 其他厂商：各有相应的实时补丁工具

3.2 最小化安装原则

攻击面最小化是安全的基本原则。每多安装一个软件包，就多了一个潜在的漏洞来源。

具体措施：

1. 选择最小化安装：使用”Minimal Install”选项或最小化镜像

2. 移除不必要的软件包：

   # 查看已安装的软件包 dpkg --list  # Debian/Ubuntu rpm -qa      # RHEL/CentOS 
   # 移除不需要的包 sudo apt remove --purge

3. 特别注意移除编译工具（除非确实需要）：

    

   sudo apt remove gcc g++ make  # 减少攻击者在服务器上编译恶意工具的能力 

4. 合理分区：将 /var、/tmp 和 /home 放在单独的分区上，可以应用不同的挂载选项增强安全性

3.3 入侵检测系统 (IDS)

入侵检测系统可以监控系统文件的完整性，及时发现可能的入侵行为。

AIDE（Advanced Intrusion Detection Environment）

# 安装 sudo apt install aide  # Debian/Ubuntu sudo dnf install aide  # RHEL/Fedora 
# 初始化数据库 sudo aideinit  # Debian/Ubuntu sudo aide --init  # RHEL 
# 定期检查（建议加入 cron） sudo aide --check

Rootkit Hunter (rkhunter)

sudo apt install rkhunter

# 更新数据库 sudo rkhunter --update

# 执行检查 sudo rkhunter --check

2026 年 EDR 建议

根据 2025 年安全最佳实践，传统杀毒软件对 Linux 工作负载是可选的，但 EDR（端点检测与响应）或 HIDS（主机入侵检测系统）在 2026 年强烈推荐。

原因：现代攻击者越来越多地使用”living-off-the-land”技术（利用系统自带工具进行攻击）和凭证窃取，这些手法可能绑过传统的签名式杀毒软件；而 EDR 提供行为检测和快速响应能力。

3.4 安全审计工具

Lynis —— 全面的安全审计工具

# 安装 sudo apt install lynis  # 或从官网获取最新版 
# 执行系统审计 sudo lynis audit system

# 查看报告 sudo cat /var/log/lynis-report.dat

Lynis 会检查以下方面：

• 系统启动和服务
• 软件包更新状态
• 网络配置
• SSH 配置
• 文件系统权限
• 用户账户安全
• 防火墙配置
• 并给出具体的加固建议

定期漏洞扫描

建议使用 OpenVAS 或 Nessus 进行定期的外部和认证扫描，跟踪你的技术栈相关的 CVE。

---

四、数据安全

即使你的服务器被攻破，良好的数据安全措施也能最大限度地降低损失。

4.1 数据备份（3-2-1 原则）

3-2-1 备份原则是业界公认的最佳实践：

数字	含义	说明
3	3 份副本	原始数据 + 2 份备份
2	2 种媒介	例如：本地硬盘 + 云存储
1	1 份异地	至少一份备份存放在物理上不同的地点

备份工具推荐：

• rsync：高效的增量备份
• Restic / Borg：支持加密和去重的现代备份工具
• 云服务：AWS S3、阿里云 OSS 等（开启版本控制和生命周期管理）

备份验证：定期测试备份的恢复能力，未经验证的备份等于没有备份。

4.2 使用 SSL/TLS 加密传输

确保所有 Web 服务都配置了 TLS 证书，避免数据在传输过程中被窃听或篡改。

使用 Let’s Encrypt 获取免费证书：

sudo apt install certbot python3-certbot-nginx  # 或 python3-certbot-apache 
sudo certbot --nginx -d yourdomain.com

证书自动续期：

Certbot 会自动创建 systemd timer 或 cron job 来处理续期。验证方法：

sudo certbot renew --dry-run

4.3 磁盘加密 (Data at Rest)

对于处理敏感数据的服务器，磁盘加密是合规要求。

使用 LUKS（Linux Unified Key Setup）进行全盘加密：

• 即使物理硬盘被盗，数据也无法被读取
• 密钥应安全存储（HSM、KMS 或启动时通过控制台输入）

---

五、2026 年特别建议

随着技术环境的演变，以下是 2026 年需要特别关注的安全趋势和建议。

5.1 容器化隔离

尽量在容器中运行应用程序，利用容器的命名空间和 cgroup 隔离特性限制攻击面。

Docker vs Podman 的安全对比（2026 年视角）

根据 2025-2026 年容器安全对比研究：

特性	Docker	Podman
架构	需要 root 守护进程	无守护进程，容器是用户的子进程
默认 Rootless	需要额外配置	✅ 开箱即用
内核能力	容器获得 14 个内核能力	容器仅获得 11 个内核能力
2025 年安全漏洞	多个（包括 RCE）	零个
SELinux/AppArmor 支持	支持	✅ 原生深度集成

2026 年建议：

• 新项目优先考虑 Podman，特别是在安全敏感环境（政府、金融、多用户服务器）
• 现有 Docker 工作流可继续使用，但应启用 rootless 模式

容器安全注意事项：

容器隔离并非绝对。由于容器与宿主机共享内核，内核或运行时层面的漏洞可能突破隔离边界。实践中，大多数成功的攻击都与已知漏洞（内核/runc）和弱配置（root 运行、–privileged 标志、hostPath 挂载）的组合有关。

安全配置要点：

• 避免使用 --privileged 标志
• 不要以 root 用户运行容器进程
• 限制容器的能力（capabilities）
• 使用只读根文件系统
• 限制 hostPath 挂载

5.2 启用 SELinux 或 AppArmor

强制访问控制 (MAC) 系统提供了传统自主访问控制之外的额外安全层。即使应用程序被攻破，MAC 也能限制其对系统其余部分的访问。

系统	默认发行版	特点
SELinux	RHEL、CentOS、Fedora	功能强大，策略灵活但配置复杂
AppArmor	Ubuntu、Debian、SUSE	配置相对简单，基于路径的访问控制

检查 SELinux 状态：

getenforce  # 应返回 "Enforcing" 

检查 AppArmor 状态：

sudo aa-status

不要将 SELinux 设置为 Disabled 模式。如果遇到问题，先使用 Permissive 模式（仅记录不阻止），分析日志后调整策略。

5.3 后量子密码学准备

“现在收集，以后解密”攻击是真实威胁。攻击者可能正在收集加密的 SSH 会话数据，等待量子计算机成熟后进行解密。专家估计具有密码学意义的量子计算机可能在 2030 年代中期出现。

OpenSSH 的后量子密码学支持

根据 OpenSSH 官方文档 和 GitHub 的实践：

OpenSSH 版本	后量子支持
9.0+ (2022年4月)	支持 sntrup761x25519-sha512
9.9+ (2024年)	新增 mlkem768x25519-sha256
10.0+ (2025年4月)	mlkem768x25519-sha256 成为默认
10.1+	使用非后量子算法时会发出警告

你应该做什么：

1. 检查当前 OpenSSH 版本：

   bash

   ssh -V

2. 升级到 OpenSSH 9.0+（如果尚未升级）

3. 确认后量子密钥交换已启用：

   bash

   ssh -Q kex | grep -E 'sntrup|mlkem' 

对于大多数用户，如果运行 OpenSSH 9.0 或更高版本，无需额外配置，客户端会自动协商新算法。GitHub 已于 2025 年 9 月在其平台启用后量子 SSH 密钥交换。

5.4 硬件安全强化

• 设置 UEFI/BIOS 管理员密码
• 启用 Secure Boot
• 禁用外部启动设备
• 保持 NIC、RAID 和 BIOS 固件更新
• 利用 TPM 2.0 进行可信启动和远程证明，检测启动级别的篡改

5.5 关注重大漏洞：regreSSHion 案例分析

CVE-2024-6387 (regreSSHion) 是一个典型的高危漏洞案例，值得深入学习：

漏洞概况：

• 2024 年 7 月 1 日披露
• 影响 OpenSSH 服务器 (sshd)
• 无需身份验证即可远程执行代码，获取 root 权限
• 这是近 20 年来首个 OpenSSH 未认证 RCE 漏洞

受影响版本：OpenSSH 8.5p1 – 9.8p1

攻击难度：

• 需要约 10,000 次尝试才能成功触发竞态条件
• 以默认配置（100 连接/120 秒）计算，约需 3-4 小时
• 32 位系统比 64 位系统更容易被利用（ASLR 范围更小）

教训：

1. 这是一个回归漏洞（2006 年已修复的漏洞在 2020 年的代码变更中意外重新引入）
2. 及时更新的重要性：漏洞公布时，全球有超过 700 万个暴露的 OpenSSH 实例受影响
3. 深度防御的价值：即使 OpenSSH 被攻破，SELinux/AppArmor、容器隔离、最小权限配置仍能限制损害

---

六、常见问题深度解答

Q1: 仅使用 SSH 密钥是否足够安全？

答案：对于普通个人用户，带有强 Passphrase 的 Ed25519 密钥已经足够安全。但对于生产环境或重要服务器，还需要额外的安全层。

SSH 密钥可能面临的风险：

风险类型	说明	缓解措施
私钥文件被盗	电脑被植入木马，或将未加密私钥备份到网盘/GitHub	设置 Passphrase；使用硬件安全密钥
跳板攻击	使用 SSH Agent Forwarding 时，中间服务器被攻破可能被利用	避免使用 Agent Forwarding；改用 ProxyJump
SSH 漏洞	如 regreSSHion (CVE-2024-6387)	及时更新；限制来源 IP

2026 年”满分”安全组合：

密钥 (Ed25519) + 硬件令牌 (FIDO2) + IP 白名单 + 及时更新

Q2: 如何在 Ubuntu 上安全配置 YubiKey？

详细步骤请参考上文 1.4 节的硬件安全密钥 (FIDO2/U2F) 部分。

关键要点：

1. 确保 OpenSSH 版本 ≥ 8.2（推荐 8.3+ 以使用 verify-required）
2. 设置 FIDO2 PIN
3. 使用 ssh-keygen -t ed25519-sk -O resident -O verify-required 生成密钥
4. 务必注册备用密钥和保留传统登录方式作为后路

Q3: 检查坏习惯清单

定期对照以下清单检查你的服务器：

•  私钥是否设置了 Passphrase？
•  ~/.ssh/authorized_keys 中是否有离职员工或旧设备的公钥？（定期清理）
•  SSH 配置是否禁用了密码登录和 Root 登录？
•  是否有未使用的服务仍在运行？
•  防火墙规则是否遵循最小开放原则？
•  自动安全更新是否正常工作？
•  最近一次备份恢复测试是什么时候？

---

📚 核心安全措施检查清单

优先级	措施	状态
🔴 关键	禁用密码登录，使用 SSH 密钥	⬜
🔴 关键	禁用 Root 直接 SSH 登录	⬜
🔴 关键	启用自动安全更新	⬜
🔴 关键	配置防火墙（默认拒绝）	⬜
🟠 重要	安装 Fail2Ban	⬜
🟠 重要	更改 SSH 默认端口	⬜
🟠 重要	启用 MFA / 硬件安全密钥	⬜
🟠 重要	配置备份（3-2-1 原则）	⬜
🟡 推荐	启用 SELinux / AppArmor	⬜
🟡 推荐	使用容器化运行应用	⬜
🟡 推荐	安装入侵检测系统	⬜
🟡 推荐	定期安全审计 (Lynis)	⬜
🔵 前瞻	升级到支持后量子密码学的 OpenSSH	⬜

定期维护任务

频率	任务
每日	检查自动更新日志
每周	审查 Fail2Ban 封禁日志
每月	运行 Lynis 安全审计
每月	检查并关闭不必要的服务
每季度	清理 authorized_keys 和用户账户
每季度	测试备份恢复能力

---

📖 参考资源

安全最佳实践：

• Linux Server Hardening Security Tips – nixCraft
• Linux Server Security Best Practices – Rackspace
• Best Security Practices for Dedicated Servers in 2026

SSH 与密钥管理：

• OpenSSH Post-Quantum Cryptography
• Securing SSH with FIDO2 – Yubico
• GitHub Post-Quantum SSH Security

漏洞与威胁情报：

• regreSSHion CVE-2024-6387 分析 – Qualys
• Linux Kernel CVEs 2025 – CIQ

容器安全：

• Docker vs Podman 2026 – Last9
• Containers in 2025: Docker vs Podman – Linux Journal

零信任与 VPN：

• Tailscale Zero Trust Report 2025
• Fail2Ban Best Practices
• Fail2Ban Alternatives – Sunucun