Linux VPS安全：威胁、防护层级与加固指南

3 分钟阅读·Matthieu·securitysshfirewallfail2banlinuxdebianubuntuvps-hardening|

按防护层级组织的Linux VPS安全指南，而非随机技巧列表。涵盖威胁模型、SSH加固、防火墙、Fail2Ban、用户权限、自动更新和VPN访问，适用于Debian 12和Ubuntu 24.04。

你刚刚创建了一台Linux VPS。90秒内，自动化扫描器已经找到它。第一个小时内，你的SSH日志就会显示来自僵尸网络（botnet）的数百次暴力登录尝试，这些网络循环尝试常见的用户名和密码。

这不是假设。每台公开的服务器都会遇到这种情况。

大多数VPS安全指南给你一份20多条技巧的编号清单，没有结构和优先级。本指南采用不同的方法。它将安全映射为同心防护层，每一层进一步减少攻击面。你将理解哪些攻击实际上会打击你的服务器，以及哪些防御手段能阻止它们。

如果你是第一次配置VPS，从前5个安全步骤开始。仅那一节就能阻止超过90%的自动化攻击。

如果你是有经验的管理员，使用跳转链接直接进入你需要的层级。

本指南涵盖Debian 12和Ubuntu 24.04。所有命令均在两个系统上经过测试。

新的Linux VPS面临哪些攻击？

一台拥有公网IP的新VPS在上线后数秒内就面临自动化攻击。僵尸网络持续扫描整个IPv4空间。最常见的攻击是SSH凭证填充（credential stuffing）、针对暴露服务的端口扫描，以及利用未打补丁软件中的已知漏洞。

理解威胁模型能让本指南中的每条建议都变得清晰。以下是实际发生的情况：

自动化扫描

僵尸网络持续扫描完整的IPv4地址范围。Shodan和Censys等项目索引所有可达端口。你的服务器并非被特意针对，它被发现只是因为它存在。

在配置后的第一小时内，预计会有：

  • 来自分布式IP的200+次SSH登录尝试
  • 探测数据库（3306、5432）、Web服务器（80、443）和管理面板的端口扫描
  • 针对已知漏洞路径的请求（/wp-admin、/phpmyadmin、/.env）

凭证填充与暴力破解

攻击者使用泄露的凭证数据库，针对你的SSH服务尝试用户名/密码组合。他们循环尝试root、admin、ubuntu、deploy等常见名称。如果启用了密码认证且密码较弱，沦陷只需几分钟。

供应链攻击与入侵后行为

一旦进入服务器，攻击者会安装挖矿程序、添加SSH后门，或将你的服务器用作进一步攻击的中继。有些人会安装能在重启后存活的rootkit。被攻陷的VPS可用于攻击其他服务器，这会让你对这些流量承担责任。

还有一个日益增长的趋势：针对软件包仓库和安装脚本的供应链攻击。许多配置指南中常见的curl | bash模式，会在没有验证的情况下执行来自互联网的任意代码。避免使用它。下载脚本，验证校验和，然后再执行。

通过版本信息暴露进行侦察

攻击者对你的服务器软件进行指纹识别以找到匹配的漏洞利用代码。一个返回Server: nginx/1.24.0的Web服务器，或暴露确切OpenSSH版本的SSH banner，会告诉攻击者应该尝试哪些CVE。隐藏版本信息是个小步骤，但它消除了低成本的定向攻击。在本指南和链接的教程中，你将看到如何为每个服务禁用版本信息披露。

这对你的防御意味着什么

本指南中的每一层都针对特定的攻击向量：

攻击向量 防御层级
SSH暴力破解 SSH密钥认证、Fail2Ban
端口扫描 防火墙（UFW/nftables）
凭证填充 禁用密码认证、非root用户
未打补丁的漏洞 自动安全更新
对管理服务的未授权访问 VPN（WireGuard/Tailscale）
权限提升 用户权限、sudo

新VPS的前5个安全步骤是什么？

如果你什么都不做，就做这五件事。它们耗时不到15分钟，能阻止绝大多数自动化攻击：1）更新所有软件包，2）创建具有sudo权限的非root用户，3）配置SSH密钥认证并禁用密码，4）启用防火墙，5）安装Fail2Ban。

以下是快速入门序列。每个步骤都链接到详细教程。

1. 更新所有软件包

apt update && apt upgrade -y

这会修补已知漏洞。在新的VPS上，基础镜像可能落后安全补丁数周或数月。

2. 创建非root用户

adduser deploy
usermod -aG sudo deploy

以root身份工作意味着任何错误或漏洞利用都拥有完整的系统访问权限。sudo用户需要明确的权限提升。

3. 配置SSH密钥认证

在你的本地机器上，如果还没有Ed25519密钥对，生成一个：

ssh-keygen -t ed25519 -C "your-email@example.com"

将其复制到服务器：

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@your-server-ip

然后在服务器上编辑/etc/ssh/sshd_config：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

重启SSH。在Ubuntu 24.04上，SSH使用基于socket的激活方式：

# Ubuntu 24.04
sudo systemctl restart ssh.socket

# Debian 12
sudo systemctl restart sshd

断开连接前先验证：打开第二个终端，确认可以用密钥以新用户身份登录。在验证访问之前，永远不要关闭当前会话。

4. 启用防火墙

# 安装UFW（Ubuntu预装，Debian需要安装）
sudo apt install ufw -y

# 启用前先放行SSH
sudo ufw allow ssh

# 启用防火墙
sudo ufw enable

# 验证
sudo ufw status

你应该看到SSH（端口22）列为ALLOW。其他所有流量默认拒绝。

5. 安装Fail2Ban

sudo apt install fail2ban -y

创建本地jail配置：

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 1800
EOF

在Debian 12上，Fail2Ban需要从journald而非auth.log读取：

# 仅Debian 12
echo "sshd_backend = systemd" | sudo tee -a /etc/fail2ban/paths-debian.conf

启动并启用服务：

sudo systemctl enable --now fail2ban

验证其正在运行：

sudo systemctl status fail2ban
sudo fail2ban-client status sshd

你应该看到sshd jail列为活动状态，当前封禁IP数为0。数小时内，你将开始看到封禁记录。

SSH加固如何保护你的服务器？

SSH是你服务器的前门，也是自动化攻击的首要目标。SSH加固意味着用加密密钥替换密码认证、禁用root登录，以及限制服务器接受哪些用户和算法。这些变更将SSH攻击面从"尝试任何密码"缩减为"提供这个确切的私钥"。

除了前5个步骤中涵盖的基础内容，经过加固的SSH配置还包括：

  • 仅使用Ed25519密钥。 比RSA更快更安全。密钥为256位，但提供128位安全性，相当于RSA-3072。
  • 空闲超时。 断开非活动会话以防止被遗弃的终端被劫持：
ClientAliveInterval 300
ClientAliveCountMax 2
  • 限制用户。 将SSH访问限制到特定账户：
AllowUsers deploy
  • 禁用未使用的认证方式：
KbdInteractiveAuthentication no
X11Forwarding no
  • 隐藏SSH版本banner。 虽然OpenSSH不允许完全隐藏其协议版本，但你可以移除自定义banner并限制信息泄露：
Banner none
DebianBanner no

修改sshd_config后，在重启前验证语法：

sudo sshd -t

如果命令没有输出，配置有效。然后重启SSH并从第二个终端验证仍能登录。始终从第二个会话测试。如果配置有问题，你的现有连接仍然有效。

有关Debian 12和Ubuntu 24.04经过测试配置的完整SSH加固教程，请参见。

为什么你的VPS需要防火墙？

防火墙控制哪些网络流量能到达你的服务器。没有防火墙，你运行的每个服务都暴露在互联网上。端口5432上的数据库、端口3000上的开发服务器、端口6379上的Redis实例：所有人都可访问。防火墙确保只有你明确开放的端口才能访问。

Debian 12和Ubuntu 24.04都使用nftables作为内核级数据包过滤框架。UFW（Uncomplicated Firewall，简单防火墙）作为友好的用户界面位于其上层。对于大多数VPS用例，UFW是正确的选择。

UFW vs nftables：何时使用哪个

UFW nftables
最适合 单服务器配置、Web应用 多服务器、高级路由
学习曲线 几分钟 数小时到数天
默认启用 Ubuntu（预装） Debian 12（后端）
规则语法 ufw allow 443/tcp 表、链、规则表达式
何时切换 不适用 需要逐包日志、限速规则、复杂NAT

使用UFW的典型Web服务器防火墙配置：

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

验证规则：

sudo ufw status numbered

每个开放的端口都是潜在的入口点。只开放你的应用程序需要的端口。如果你移除了某个服务，同时移除其防火墙规则。

有关包括nftables规则、限速和端口访问控制的详细防火墙配置，请参见。

Fail2Ban如何阻止暴力破解攻击？

Fail2Ban监控日志文件（或Debian 12上的journald）以检测重复失败的认证尝试，并使用防火墙规则临时封禁违规IP地址。它将暴力破解攻击从"尝试10000个密码"变成"尝试3个密码，被封禁30分钟，再从另一个IP重新开始"。

工作原理

  1. Fail2Ban监控SSH认证日志
  2. 在findtime时间内超过maxretry次失败后，创建防火墙规则封禁该IP
  3. bantime到期后，规则被移除
  4. 持续攻击者循环切换IP，但速率限制使凭证填充变得不切实际

VPS的推荐设置

默认设置对公开服务器来说过于宽松。以下是生产配置：

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 3600
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 86400
EOF

此配置在3次失败后封禁IP 1小时。如果同一IP再次出现，每次封禁时间翻倍，最长24小时。这比固定封禁时间更有效，因为自动化扫描器最终会降低对你服务器的优先级。

重启Fail2Ban以应用：

sudo systemctl restart fail2ban

检查活动封禁：

sudo fail2ban-client status sshd

实时观察封禁：

sudo tail -f /var/log/fail2ban.log

有关涵盖Nginx、Postfix和其他服务自定义jail的完整Fail2Ban设置指南，请参见。

用户权限如何减少攻击面？

以root身份运行服务意味着如果该服务被攻陷，攻击者将获得完整的系统访问权限。最小权限原则（principle of least privilege）意味着每个进程以其所需的最低权限运行。Web服务器被攻陷不应该给予对数据库、SSH密钥或系统配置的访问权限。

关键实践

永远不要以root身份运行应用服务。 Web服务器、数据库和应用运行时应该各自拥有系统用户：

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/myapp myapp

--system标志创建没有家目录登录的用户。--shell /usr/sbin/nologin防止交互式登录。此用户可以运行你的应用程序，但不能SSH登录或执行任意命令。

限制sudo访问。 只有sudo组中的用户才应该拥有提升的权限。审计谁有sudo权限：

getent group sudo

正确设置文件权限。 包含密码或API密钥的配置文件不应该对所有人可读：

# 将配置文件限制为仅所有者可访问
sudo chmod 600 /etc/myapp/config.env
sudo chown myapp:myapp /etc/myapp/config.env

# 验证
ls -la /etc/myapp/config.env

你应该看到-rw-------权限，意味着只有所有者可以读写。

使用环境文件存储密钥。 不要在配置文件中硬编码凭证，而是创建一个权限受限的专用环境文件：

sudo tee /etc/myapp/env > /dev/null << 'EOF'
DB_PASSWORD=your-generated-password
API_KEY=your-api-key
EOF

sudo chmod 600 /etc/myapp/env
sudo chown myapp:myapp /etc/myapp/env

在systemd单元中用EnvironmentFile=/etc/myapp/env引用它。使用openssl rand -base64 32生成密码，而不是手动选择。

有关Linux用户管理、sudo配置和权限模型的完整指南，请参见。

为什么要自动化安全更新？

未打补丁的软件是最常被利用的攻击向量之一。当漏洞披露后，攻击者在数小时内就开始扫描未打补丁的服务器。手动更新意味着你的服务器从漏洞披露到你下次记得运行apt upgrade之间都处于易受攻击状态。自动安全更新缩小了这个窗口。

设置unattended-upgrades

Ubuntu 24.04在其默认服务器安装中包含unattended-upgrades，但某些VPS提供商会提供不含它的精简镜像。Debian 12也需要安装。在任一发行版上，如果尚未安装请先安装：

sudo apt install unattended-upgrades apt-listchanges -y
sudo dpkg-reconfigure -plow unattended-upgrades

验证其是否激活：

cat /etc/apt/apt.conf.d/20auto-upgrades

你应该看到：

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

"1"表示每天。软件包列表每天更新，安全补丁自动安装。

什么内容会被更新

默认情况下，只安装来自官方仓库的安全更新。这是生产服务器的正确设置。功能更新和主版本变更仍需要手动干预，这防止了无人值守升级破坏你的应用程序。

监控更新

检查自动安装了什么：

sudo cat /var/log/unattended-upgrades/unattended-upgrades.log

通过编辑/etc/apt/apt.conf.d/50unattended-upgrades设置已应用更新的邮件通知：

Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";

对于内核更新需要重启时的自动重启处理：

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

只有当你的应用程序能优雅处理重启时才启用自动重启。对于大多数配置，每周手动检查比意外重启更好。

有关包括监控和故障排除的完整设置指南，请参见。

何时应该为VPS添加VPN访问？

当你运行不应该暴露在公网的服务时添加VPN访问：管理面板、数据库、监控仪表板或内部API。VPN创建一个加密隧道，使这些服务只能从你私有网络上的设备访问。不必向所有人开放端口3000并寄希望于你的认证能撑住，而是将其从互联网完全关闭，通过VPN访问。

WireGuard vs Tailscale

WireGuard Tailscale
配置时间 每个节点15-30分钟 总计2-5分钟
配置方式 手动密钥交换、配置文件 SSO登录、自动化
NAT穿透 手动端口转发 自动
控制权 完全掌控，你管理一切 协调服务器由第三方控制
费用 免费，自托管 免费（最多100台设备）
最适合 固定基础设施、完全控制 团队、动态设备、快速配置

选择WireGuard：当你想要完全控制网络、拥有静态基础设施，并且熟悉管理密钥对和配置文件时。

选择Tailscale：当你需要跨多台设备快速配置、与团队协作，或想要无需端口转发的自动NAT穿透时。

两者底层都使用WireGuard协议。Tailscale是带编排的WireGuard。

哪些内容应该放在VPN后面

  • 数据库端口（PostgreSQL 5432、MySQL 3306、Redis 6379）
  • 管理面板（phpMyAdmin、Adminer、Grafana）
  • 监控端点（Prometheus、Node Exporter）
  • 不面向公众的内部API
  • SSH访问（双重保险：密钥认证 + VPN）

一个常见模式：为公共Web应用保持80和443端口开放，其他所有内容通过VPN。你的防火墙规则变为：

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 51820/udp  # WireGuard
# 仅允许VPN子网的SSH
sudo ufw allow from 10.0.0.0/24 to any port 22

有关在VPS上分步配置WireGuard和Tailscale的教程，请参见。

更改SSH端口呢？

许多指南建议将SSH从22端口改到一个高编号端口。这是通过模糊性实现安全（security through obscurity）。它能阻止只尝试22端口的最懒惰的机器人，但不能阻止任何运行端口扫描的攻击者，而端口扫描只需几秒钟。

实际代价：你现在需要在每个SSH命令中记住-p 2222，在每个部署脚本和CI流水线中配置它，如果忘记还会有锁定自己的风险。带有Fail2Ban的SSH密钥认证提供了真正的安全。更改端口增加了操作复杂性，但收益微乎其微。

同样的逻辑适用于禁用IPv6。如果你的服务器有IPv6地址，禁用它并不会减少攻击面，反而会破坏未来的兼容性。改为将防火墙配置为同时支持IPv4和IPv6。

安全层级概览

本指南中的每一层都针对防御的特定部分。以下是它们的叠加方式：

层级 保护内容 优先级
系统更新 修补已知漏洞 首先执行
用户权限 限制被攻陷的影响范围 首先执行
SSH加固 阻止未授权的远程访问 首先执行
防火墙 控制网络暴露 首先执行
Fail2Ban 减缓暴力破解攻击 首先执行
自动更新 长期保持补丁最新 第一周内设置
VPN访问 隐藏内部服务 运行非公开服务时
内核加固 限制漏洞利用技术 高级、生产系统
审计日志 事后检测入侵 高级、合规要求

前五层对任何连接互联网的服务器都是不可或缺的。其余层根据你运行的内容和合规要求增加深度。

没有单独一层是足够的。没有防火墙的SSH加固仍然使服务暴露。没有自动更新的防火墙使已知漏洞保持开放。这些层协同工作，每一层捕获其他层遗漏的内容。

何时应该改用托管托管？

如果安全管理占用了你构建产品的时间，考虑托管主机（managed hosting）。这不是失败，而是资源分配决策。

应该考虑托管主机的迹象：

  • 你运营生产服务但没有时间监控安全公告
  • 你的团队缺乏Linux管理经验
  • 你需要合规认证（SOC 2、ISO 27001）但无法配备审计人员
  • 你之前曾被攻陷，但缺乏调查的专业知识

来自Virtua Cloud等提供商的托管服务器处理操作系统补丁、防火墙管理、入侵检测和备份。你专注于应用程序，提供商负责基础设施安全层。

对于想要VPS灵活性但部分安全覆盖的团队，存在一个折中方案：为开发和测试配置非托管VPS，为生产使用托管主机。

出现问题了？

检查你的SSH访问

如果你在更改SSH配置后被锁定：

  1. 使用VPS提供商的Web控制台或串行控制台访问服务器
  2. 检查SSH配置语法：sudo sshd -t
  3. 验证你的密钥在正确用户的~/.ssh/authorized_keys中
  4. 检查SSH日志：journalctl -u ssh -n 50（Ubuntu）或journalctl -u sshd -n 50（Debian）

检查防火墙

如果服务无法访问：

sudo ufw status numbered

确保端口列为ALLOW。如果你刚启用UFW但忘记先放行SSH，使用提供商的Web控制台。

检查Fail2Ban

如果合法IP被封禁：

# 检查IP是否被封禁
sudo fail2ban-client status sshd

# 解封特定IP
sudo fail2ban-client set sshd unbanip 1.2.3.4

读取日志

日志会告诉你发生了什么：

# SSH认证
journalctl -u ssh -f     # Ubuntu 24.04
journalctl -u sshd -f    # Debian 12

# Fail2Ban活动
sudo tail -f /var/log/fail2ban.log

# 防火墙封锁（使用nftables日志时）
journalctl -k | grep nft

# 系统消息
journalctl -p err -b

养成阅读日志输出的习惯。每次出现问题，答案几乎总是在日志中。

下一步

本指南涵盖Linux VPS的安全层级。每节都链接到详细的实践教程：

如果你还没有完成前5个安全步骤，先从那里开始。然后按顺序完成教程，每个教程都建立在前一个的基础上。

Copyright 2026 Virtua.Cloud. All rights reserved.

准备好亲自尝试了吗？

几秒内部署您自己的服务器。支持 Linux、Windows 或 FreeBSD。

查看 VPS 方案