美国VPS安全怎么加固

一、先搞清楚：攻击者是怎么进来的

在加固之前，先了解真实的攻击路径，才知道该加固哪一处。绝大多数 VPS 被入侵，路径是下面这几条。

路径一，SSH 暴力破解。 互联网上有大量扫描器在 24 小时不停地扫 22 端口。攻击者的字典里最常见的是 admin、root、test、ubuntu 这些用户名，密码则是泄露密码库里的组合。这类攻击不需要任何技术门槛，是自动化的。 公开的统计里，暴力破解占 VPS 被入侵原因的绝大多数。

路径二，利用未打补丁的服务。 你的 Nginx、PHP、WordPress、面板本身都可能存在已知漏洞。这类攻击的特征是：扫描器发现某个端口的特定版本，然后调用公开的利用代码。WordPress 站点是最典型的目标，因为插件数量多、更新情况复杂。

路径三，面板和后台的弱口令。 装了宝塔、WordPress 后台、phpMyAdmin 的机器，如果密码是弱口令或者用的是默认密码，扫描器一猜就中。

路径四，Web 应用漏洞。 文件上传没限制类型、SQL 注入、命令注入、反序列化漏洞。这类攻击不需要碰 SSH，直接从 80 和 443 端口进。

路径五，密钥泄露和供应链。 你的 SSH 私钥可能存在本地的某个目录里，某个依赖包可能带着后门。这类问题在任何加固配置里都防不住，只能靠减少依赖和定期审计。

路径六，内部横向移动。 如果机器上跑着多个站点或数据库，攻破一个之后的横向移动是常见的后续动作。

加固的优先级应该按这个顺序：

优先级	动作	阻断的攻击路径	实施难度
1	禁用密码登录，只用密钥	路径一	一小时
2	防火墙只放行必要端口	路径一、二	一小时
3	卸载不需要的面板和后台	路径三	一小时
4	自动安全更新	路径二	半小时
5	fail2ban 自动封禁	路径一	两小时
6	应用层加固	路径四	视情况
7	日志审计和告警	发现所有路径	半天

查 spinservers 在售套餐与库存

这个顺序的依据是「投入产出比」和「误伤风险」：禁用密码登录效果最大且不会误伤；防火墙次之；自动更新简单但需要注意不要自动重启生产机器。

二、SSH 加固：每一步做什么、报错怎么处理

SSH 是 VPS 最重要的入口，也是加固收益最大的一步。

第一步：先确认密钥登录已经能用，再关密码登录。 这是最重要的纪律。顺序反了会把自己锁在门外。

# 生成密钥对（在你自己的电脑上，不是在服务器上）
ssh-keygen -t ed25519 -C "vps-prod-2026"

# 把公钥传到服务器
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your-server-ip

# 确认能免密登录
ssh -o PasswordAuthentication=no root@your-server-ip "echo 密钥登录正常"

必须看到「密钥登录正常」这行输出，才能进行下一步。

第二步：改配置。

# 先备份，SSH 改错了这是唯一的退路
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

编辑 /etc/ssh/sshd_config：

# 端口：改掉默认的 22
Port 2222

# 禁止密码登录
PasswordAuthentication no
PermitEmptyPasswords no

# 禁止 root 直接登录（如果你有普通用户）
PermitRootLogin no

# 只允许密钥
PubkeyAuthentication yes

# 认证尝试次数限制
MaxAuthTries 3

# 登录尝试间隔（秒）
LoginGraceTime 30

# 允许的登录用户
AllowUsers admin deploy

# 关闭 X11 转发（不用图形界面就关掉）
X11Forwarding no

# 禁止 root 用 sftp（可选，缩小攻击面）
PermitRootLogin prohibit-password

第三步：验证语法并重载。

# 检查语法，这一步必须做，语法错误会让 sshd 起不来
sshd -t

# 重载（不是 restart！restart 会中断当前连接）
systemctl reload sshd

这一步的常见报错和处理：

报错	原因	怎么处理
sshd: no hostkeys available	主机密钥没生成	ssh-keygen -A 生成
Missing privilege separation directory	权限目录不对	mkdir -p /run/sshd && chmod 755 /run/sshd
Bad configuration option	参数名写错	用 sshd -t 看具体行号
重载后连不上	配置错误	用云控制台的 VNC 登录，执行 cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config && systemctl reload sshd
改了端口后本地还连不上	防火墙没放行新端口	先放行再改 SSH 配置

zenlayer 官网机型与实时报价

第四步：保留一个备用通道。 在完全关掉密码登录之前，可以先设一个只允许密码但需要额外安全码的方式过渡：

# 过渡期配置：密码登录保留，但只对特定用户，且限制来源
PasswordAuthentication yes
Match Address 203.0.113.0/24
    PasswordAuthentication no

确认新配置完全可用之后（至少成功登录一次），再从另一个终端测试一下，确认没问题了才关掉原来的会话。

关于改端口这件事的现实评估。 改端口能把自动化扫描的效率降低一到两个数量级，因为扫描器的端口列表是固定的。但它挡不住针对 IP 的定向扫描，而且会给自己带来麻烦：以后每次连接都要记端口号、配置跳板机时要写对端口、多人协作时端口要统一。

判断标准：如果你只维护一两台机器、且有密码登录被禁的密钥方案，改不改端口都无所谓；如果你有几十台机器要统一管理，改端口的收益就大于麻烦。

三、防火墙：ufw 与 firewalld 的正确用法

防火墙的作用是把不必要的端口全部关掉。默认应该拒绝所有入站，允许所有出站，然后只对需要的端口开一个口子。

ufw（Debian/Ubuntu 默认）的用法：

# 1. 先设默认策略
ufw default deny incoming
ufw default allow outgoing

# 2. 再放行需要的端口（顺序很重要，先放行再启用）
ufw allow 2222/tcp comment "SSH"
ufw allow 80/tcp comment "HTTP"
ufw allow 443/tcp comment "HTTPS"

# 3. 检查规则
ufw status numbered

# 4. 最后启用
ufw enable

必须记住的三条纪律。

第一条，改 SSH 端口前，先放行新端口，再启用防火墙。如果你先 ufw enable 再改 SSH 端口，规则里还是 22，新端口会被挡，你只能走 VNC。

第二条，启用防火墙前先开一个定时自动解除（如果你有 root 会话在别的地方）：

# 用 at 计划 5 分钟后自动关防火墙，防止自己被锁在外面
echo "ufw disable" | at now + 5 minutes
# 确认没问题后取消
atrm $(atq | awk '{print $1}')

第三条，永远保留一个云控制台的 VNC 或救援模式入口。这是最后一道保险。

firewalld（CentOS/RHEL 默认）的用法：

# 查看当前状态和区域
firewall-cmd --state
firewall-cmd --get-active-zones

# 放行端口（永久生效）
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https

# 重载
firewall-cmd --reload

# 列出所有规则
firewall-cmd --list-all

firewalld 的一个特性要留意：它用 zone（区域）管理规则，--add-port 不加 --permanent 只在当前会话生效，重启或 reload 后失效。很多人加了规则发现重启后没了，就是这个原因。

还需要考虑的端口。

只开 80、443、SSH 三个端口是最常见的做法，但根据你的服务不同，还可能需要：

端口	用途	是否需要对外
22 / 2222	SSH	需要，但限制来源 IP 更好
80 / 443	HTTP / HTTPS	需要
3306	MySQL	绝对不要对外，只允许本地
5432	PostgreSQL	绝对不要对外
6379	Redis	绝对不要对外
27017	MongoDB	绝对不要对外
8888	宝塔面板	不需要对外，建议改随机端口
9090 / 9100	监控采集端口	不需要对外，只允许采集端

查 goodlyclouds 在售套餐与库存

数据库端口只绑本地是最重要的一条。 在 MySQL 配置里确认：

[mysqld]
bind-address = 127.0.0.1

改完重启 MySQL 后验证：

# 从外部连应该被拒绝
mysql -h your-server-ip -u root -p
# 本地连应该正常
mysql -h 127.0.0.1 -u root -p

如果你的应用和数据库不在同一台机器上，那就不能绑 127.0.0.1，要改成绑定内网 IP（如 10.0.0.5），并且用防火墙只允许内网网段访问。这两件事必须一起做，只做一件等于没做。

四、fail2ban：自动封禁暴力破解的 IP

fail2ban 的作用是监控日志，发现某个 IP 在短时间内反复登录失败就自动把它封禁一段时间。

安装：

apt install -y fail2ban      # Debian/Ubuntu
yum install -y fail2ban      # CentOS/RHEL

配置：

; /etc/fail2ban/jail.local
[DEFAULT]
# 封禁时长：1 小时
bantime = 1h
# 找茬的时间窗口：10 分钟内
findtime = 10m
# 判定为攻击的失败次数：5 次
maxretry = 5
# 封禁的 IP 列表
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1d
# 忽略本机
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
port = 2222
# Debian 12+ 用 systemd 日志的过滤器
backend = systemd
# 或者用日志文件（老系统）
logpath = /var/log/auth.log
maxretry = 5

Debian 12 和 Ubuntu 24.04 的一个变化值得注意：这些版本改用 systemd journal，旧的 /var/log/auth.log 可能不存在或不再更新，导致 fail2ban 完全不工作。判断方法：

# 看 jail 是否真的在跑
fail2ban-client status sshd

# 如果显示 0 行且没有 Total banned，说明没在解析日志
journalctl -u ssh --since "10 min ago" | head -20

如果 jail 是 inactive 的：

# 确认日志里有失败记录
journalctl -u ssh --since "1 hour ago" | grep -c "Failed"

# 修改 jail 配置改用 systemd backend
# [sshd] backend = systemd
# 然后重启
systemctl restart fail2ban
fail2ban-client status

看到被封的 IP 列表：

# 总览
fail2ban-client status

# 看某个 jail 的详情，包括当前被封的 IP 和失败次数
fail2ban-client status sshd

# 手动封一个 IP
fail2ban-client set sshd banip 203.0.113.100

# 手动解封
fail2ban-client set sshd unbanip 203.0.113.100

解封的命令在配置里被误锁时特别有用。 记住它比记住配置文件的路径更有用。

除了 SSH，还可以给其他服务配 jail。 比如给 Nginx 的 401/403 页面配一个（防密码喷洒）、给 WordPress 的 wp-login 配一个（防后台爆破）：

sakuraclouds 官网机型与实时报价

[nginx-http-auth]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 3
findtime = 10m
bantime = 1h

五、系统补丁：什么时候更新、更新什么

补丁策略不应该是一刀切的「全部自动更新」或「永不更新」，而要分类型处理。

第一类：安全补丁，应该尽快打。 这类补丁修复的是已被利用的漏洞。

# Debian/Ubuntu：只装安全更新，不动其他包
apt update
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# 手动看安全更新
apt list --upgradable | grep -i security

第二类：内核更新，需要重启生效。 这是最容易被忽略的一类。unattended-upgrades 默认配置里 Automatic-Reboot 是 false，所以内核更新后不会自动重启，你的机器实际仍然跑着旧内核。

# 查当前内核和已安装内核
uname -r
dpkg -l | grep linux-image

# 有更新的内核就说明需要重启
ls /var/run/reboot-required 2>/dev/null && echo "需要重启"

内核更新的正确做法：先在预发环境验证，再在低峰期手动重启。不要在业务高峰期自动重启。

第三类：应用层更新（PHP、WordPress、插件）。 这类风险最高，因为自动更新可能引入不兼容。

PHP 的更新策略：小版本自动更新，大版本手动。

# 只允许小版本自动更新
apt install -y unattended-upgrades
cat > /etc/apt/apt.conf.d/51unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename}-updates,label=Debian-Security";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
};
Unattended-Upgrade::Package-Blacklist {
        "php8.2";
        "php8.2-fpm";
};
EOF

WordPress 的更新策略：核心版本跟随 WordPress 官方发布节奏更新（他们发布的是经过测试的版本），但插件要逐个评估。有些插件自动更新会破坏站点布局。

第四类：不用更新的东西。 装了就别用的服务应该卸掉而不是留着打补丁。

# 列出所有监听中的端口和对应进程
ss -tulnp

# 找出所有装过的包
dpkg -l | grep ^ii | awk '{print $2}'

查看 serverfield 当前月价与库存

一个实用原则：服务器上运行的服务数量，应该和你真正需要的数量相等。 每多一个服务就多一份补丁负担、多一个攻击面、多一点内存占用。

六、入侵迹象排查：怎么判断机器被动过

加固做了不代表一定没被入侵过。这一节给出排查的方法。

第一类，看登录记录。

# 最近的登录记录
last -a -n 50

# 失败的登录尝试（找暴力破解）
lastb -a -n 50 | head -30

# 当前登录的用户
who
w

# 找可疑的成功登录：不是你自己常用 IP 的
last -a | awk '{print $3}' | sort | uniq -c | sort -rn

看到陌生的 IP、陌生的用户名、深夜的登录记录，就要往下查。

第二类，看 SSH 密钥。

# 列出所有用户的 authorized_keys
find / -name authorized_keys -type f 2>/dev/null -exec ls -la {} \; -exec cat {} \;

# 列出所有用户的 SSH key 数量和指纹
for f in $(find / -name authorized_keys -type f 2>/dev/null); do
  echo "=== $f ==="
  ssh-keygen -l -f "$f"
done

你认识的密钥指纹应该和你本地 ~/.ssh/id_ed25519.pub 的指纹一致。 多出来的任何一条都要查清楚。

第三类，看计划任务。 入侵者常用来保持权限。

# root 和所有用户的 crontab
for u in $(cut -d: -f1 /etc/passwd); do
  crontab -l -u "$u" 2>/dev/null | grep -v '^#' | grep -v '^$' && echo "^^^ 属于用户 $u"
done

# 系统级的 cron
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/

# systemd 定时器
systemctl list-timers --all

第四类，看进程。

# CPU 占用最高的进程
ps aux --sort=-%cpu | head -15

# 所有可执行文件路径，挖矿程序常藏在奇怪的地方
ls -la /proc/*/exe 2>/dev/null | grep deleted

# 监听端口对应的进程
ss -tulnp

# 挖矿特征：检查常见的矿工文件名
find / -name "kdevtmpfsi" -o -name "kinsing" -o -name "*.xmrig*" 2>/dev/null

第五条命令是挖矿木马排查的关键：/proc/*/exe 里带 deleted 的进程，表示它的可执行文件已经被删除但进程还在跑——这是最常见的木马隐藏手法。

第五类，看网络连接。

# 所有 established 连接，看有没有连到奇怪的地方
ss -tnp state established

# 找出所有对外连接的目的 IP 和端口
ss -tnp | awk 'NR>1{print $5}' | sort | uniq -c | sort -rn | head -20

第六类，看文件改动。

# 最近 7 天改动的文件
find /etc /usr/bin /usr/sbin /bin /sbin -mtime -7 -type f -exec ls -la {} \;

# 查有没有新增的定时任务或启动脚本
ls -la /etc/rc.local /etc/init.d/ 2>/dev/null

第七类，看 Web 目录。

# Web 目录里有没有最近新增的可执行文件
find /var/www -mtime -7 -type f \( -name "*.php" -o -name "*.jsp" -o -name "*.sh" \) -exec ls -la {} \;

# 有没有 webshell 特征的代码
grep -rl "eval(\|base64_decode(\|system(\|shell_exec(\|passthru(" /var/www 2>/dev/null | head -20

发现入侵后的处理顺序（很重要）：先断网取证，再清理，最后恢复。

# 1. 立刻断网（保留 SSH 连接，防止把自己也关在外面）
# 用 iptables 只允许自己的 IP
iptables -A INPUT -s 你的IP -j ACCEPT
iptables -A INPUT -j DROP

# 2. 保存现场证据
tar czf /root/evidence-$(date +%F).tgz /var/log/ /etc/ /root/.ssh/

# 3. 记录关键信息
last -a -n 100 > /root/evidence/last.txt
ss -tnp > /root/evidence/netstat.txt
ps aux > /root/evidence/ps.txt

# 4. 然后才是清理

为什么不能直接清理。 因为你不知道攻击者留了几个后门。直接删文件可能删掉一个还有另外五个在跑。正确做法是：用备份恢复到一个已知干净的环境，然后逐项核对数据，或者干脆重装系统（最彻底），然后逐个恢复数据并检查。

查看 干杯cloud 当前月价与库存

一个重要原则：如果你不能确定机器是否干净，就重装系统。 清理脚本无法保证抹掉所有痕迹——内核层面的 rootkit、手工修改的二进制、日志被清理过的痕迹，这些脚本都查不出来。重装系统加逐项数据核对，是唯一可靠的方法。

七、常见误区：这些做法看着安全其实没用

误区一：改复杂密码就够了。 复杂密码挡不住自动化扫描。扫描器一天试几百万次，任何 12 位密码在字典面前都不够看。密码强度是最后一道防线，不是第一道。 第一道是禁用密码登录。

误区二：改 SSH 端口就安全了。 改端口降低的是自动化扫描的效率，不是定向攻击的门槛。知道你的 IP 的攻击者扫一个全端口段只要几分钟。改端口必须和防火墙、密钥登录一起做才有意义。

误区三：装个安全面板就够了。 面板本身是需要打补丁的软件，而且它引入了新的端口（通常是 8888）和新的 root 权限绑定。对一台只跑一个静态站或简单 API 的机器，装面板是增加风险不是降低风险。

误区四：云厂商的快照能防住一切。 快照和备份一样，只防误操作，防不住机房事故、商家迁移、账号封禁，也防不住已经被入侵的环境（快照会把木马一起恢复回去）。快照回滚到一个被入侵的时间点，等于把木马也装回去。

误区五：只防外面，不防里面。 服务器上如果有多个站点共用一台机器，一个站点的漏洞可以横向攻击另一个站点。数据库 Redis 的端口暴露在外是最常见的问题——扫描器发现 6379 开放后会尝试写入，Redis 未授权访问可以直接拿到 root shell。

Redis 未授权访问的验证方法：

# 正常情况下应该返回 NOAUTH 错误
redis-cli -h your-server-ip -p 6379 ping
# 返回 (error) NOAUTH Authentication required. 说明配置正确

如果返回 PONG，说明任何人都能连上，必须立刻处理。

误区六：以为云厂商的防火墙规则就够了。 云防火墙保护的是网络入口，但应用层的问题它管不了：弱口令的后台、没打补丁的 WordPress、暴露的管理员路径。云防火墙和系统防火墙是两层，缺一不可。

误区七：把宝塔面板的默认安全设置当成安全。 装了面板之后如果只做了「改默认密码」这一件事，面板依然是高风险目标。

误区八：不做日志留存。 被入侵后如果 /var/log 被清空，你就完全失去了溯源能力。

# 确认日志轮转配置，保留 30 天
grep -E "^\s*(weekly|daily|monthly|rotate|rotate|compress|delaycompress|sharedscripts)" /etc/logrotate.conf

误区九：把「没被入侵」当成「加固做完了」。 这两件事不一样。加固做完了只代表已知的路径被堵住，不代表没有未知漏洞。持续更新和持续监控才是长期的事，一次性配置只是起点。

查 cubecloud 在售套餐与库存

误区十：只在服务器上做安全，不在自己的电脑上做。 你的本地电脑才是密钥和密码的源头。SSH 私钥要放在有密码保护的密钥链里，不要放在桌面或网盘同步目录里；密码用密码管理器生成和保存，不要多个网站复用同一个。攻击者从你的电脑拿到私钥，比从公网上爆破 SSH 容易得多。

八、什么情况下不该做全套加固

这一节按公开事实说明不适用的场景——机房位置、线路类型、计费方式、IP 资源，不评价任何商家好坏。

场景一：机器只用来跑一次性任务，任务结束就销毁。 这种机器上没有任何值得攻击的数据，也没有值得持久化的服务。替代方案：只做最基本的两件事——用密钥登录而不是密码、把 SSH 端口从 22 改掉。跳过防火墙、fail2ban、监控告警这些需要持续维护的部分。

场景二：IP 资源是业务的核心，机器必须接受来自任意 IP 的连接。 有些场景（比如作为跳板、或者对外提供 API 给不确定来源的客户端）需要让任意 IP 都能连上某个端口。这时「限制来源 IP」的加固方案不适用。替代方案：把 SSH 的密码登录彻底关掉（这样 SSH 只接受密钥），同时对必须开放的端口用强认证和应用层限流来保护，而不是依赖 IP 白名单。

场景三：机房位置决定了你的运维方式是远程批量管理。 如果你有几十台分布在不同机房的机器，每次改 SSH 配置都要单独登录是低效的。替代方案：不要逐台手工改，用配置管理工具（Ansible、SaltStack）统一推送 SSH 配置和防火墙规则。这时候「可批量下发」比「手工精调」更重要。

场景四：计费方式是流量计费，加固动作本身消耗流量。 fail2ban 和监控的告警请求、日志上传都从配额里扣。RosCloud-01 每月只有 1024 GB 流量，LAX-STARTER 是 5000 GB。替代方案：日志做本地轮转不上传，告警走消息推送而不是自建监控采集，减少流量占用。

场景五：宿主机层面的隔离不可控。 有些 VPS 跑在共享的宿主机上，你无法控制同宿机的其他租户，也无法完全确定宿主机本身没有被入侵。替代方案：在应用层做隔离——每个站点用独立的系统用户、独立的数据库账号（权限只给自己库）、独立的文件目录。同时把凭据加密存储，这样即使宿主机被入侵，攻击者拿到的也只是密文。

tmhhost 官网机型与实时报价

场景六：你用的是带面板的方案且不打算改。 如果业务团队强烈依赖面板的图形化操作，强行改成裸装会增加培训成本。替代方案：接受面板存在的风险，但把安全配置做满——改随机端口、开启安全入口、限制来源 IP 或只允许通过 SSH 隧道访问、关闭不必要的插件、定期检查面板版本。这样面板的风险等级可以降到和裸装接近。

九、一份可以直接照做的加固清单

第一阶段：新机器开出来的一个小时内必须做完。

# 1. 更新系统
apt update && apt upgrade -y

# 2. 创建普通用户（不要日常用 root）
adduser deploy
usermod -aG sudo deploy

# 3. 给普通用户配密钥
mkdir -p /home/deploy/.ssh
cp ~/.ssh/id_ed25519.pub /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

# 4. 改 SSH 配置（改完先 sshd -t 验证）
# Port 2222 / PasswordAuthentication no / PermitRootLogin no

# 5. 装并配置 fail2ban
apt install -y fail2ban
# 编辑 /etc/fail2ban/jail.local

# 6. 配防火墙
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

# 7. 重载 SSH 并验证
systemctl reload sshd
sshd -t

第二阶段：一周内完成。

装 fail2ban 并配置 jail；确认数据库和 Redis 绑本地；配置日志轮转保留 30 天；开启自动安全更新（不自动重启）；关掉不必要的服务：

# 看所有在监听的服务
ss -tulnp

# 常见可以关的
systemctl disable --now telnet.socket
systemctl disable --now rsh.socket
systemctl disable --now ftp.socket

# 关掉不需要的 mail 服务
systemctl disable --now postfix
systemctl disable --now exim4

第三阶段：一个月内完成。

配置日志外发和告警；设置每周一次的检查任务（更新、fail2ban 状态、磁盘、异常登录）；做一次入侵迹象排查（用第六节的命令）；给重要的服务配置只读账号和最小权限。

一个持续的自检脚本，每月跑一次：

#!/bin/bash
# monthly_audit.sh
echo "=== 1. 未更新的安全更新 ==="
apt list --upgradable 2>/dev/null | grep -i security | head -10

echo "=== 2. SSH 配置检查 ==="
grep -E "^(PasswordAuthentication|PermitRootLogin|Port)" /etc/ssh/sshd_config

echo "=== 3. 防火墙状态 ==="
ufw status | head -10

echo "=== 4. fail2ban 被封 IP 数 ==="
fail2ban-client status sshd 2>/dev/null | grep "Currently banned"

echo "=== 5. 异常登录（最近 7 天）==="
last -a -n 100 | head -20

echo "=== 6. 可疑进程（exe 已删除）==="
ls -la /proc/*/exe 2>/dev/null | grep deleted

echo "=== 7. 磁盘使用 ==="
df -h / | tail -1

echo "=== 8. 需要重启 ==="
[ -f /var/run/reboot-required ] && echo "需要重启" || echo "无需重启"

echo "=== 9. 开放的端口 ==="
ss -tulnp | grep LISTEN

第五阶段：每季度的复检。

每季度重跑一次第九节的 monthly_audit.sh，并且做一次演练。

演练一：验证 SSH 加固是否真的生效。 在另一个终端用密码登录，预期结果是收到 Permission denied (publickey)。如果密码居然能登录成功，说明 PasswordAuthentication no 没生效。

演练二：验证 fail2ban 链路。 用一个测试账号故意连续输错密码 6 次，然后看 IP 有没有被封：

# 在另一台机器上故意失败 6 次
ssh -o NumberOfPasswordPrompts=6 baduser@your-server-ip

# 在服务器上看封禁状态
fail2ban-client status sshd

如果 IP 没被封，说明 fail2ban 没有在解析这个日志。这是必须验证的，因为 fail2ban 配置写对了但没在跑的情况非常常见。

演练三：验证告警链路。 触发一次告警（比如手动把磁盘用满到 90%，或者发一条测试消息），确认消息真的到了你的手机或邮箱。告警链路不做测试，就默认它是坏的。

演练四：验证备份可恢复性。 挑一台机器，在临时目录里从备份恢复一个文件，确认内容正确。这一步和加固同等重要——被入侵后的恢复速度取决于你手上的备份。

第四阶段：给四类人的建议。

个人站长、单站点。 做第一阶段和第二阶段就够了。重点是密钥登录加防火墙。不要装面板，不要过度设计。预算 0 美元。

中小站长、多个站点共用一台机器。 做全部四阶段，加上：每个站点用独立的系统用户和数据库账号、Web 目录权限隔离、开启登录告警。这一层隔离比多装安全软件有用。

有真实收入、有后台系统的团队。 全部四阶段，加上：日志集中收集、关键操作审计（谁在什么时候改了配置）、密钥集中管理、定期做入侵演练（自己模拟一次爆破，验证告警链路通不通）。演练是唯一能证明加固有效的办法。

第四类：对外提供 API 或服务的团队。 全部四阶段，加上：API 层限流和鉴权、密钥轮换机制、WAF 或反代层的规则、独立的监控机器（监控机不跑业务，所以它被入侵了也不会影响业务）。这一类场景的关键原则是假设自己迟早会被扫到，设计成被扫到也不影响业务。

最后三条通用原则。

第一，安全配置的变更要走和发布一样的流程。 改防火墙规则、改 SSH 配置这些操作一旦出错会把所有人关在门外，所以要有第二个人复核，最好在低峰期做，并且提前准备好回滚命令。

第二，权限要从最小开始给。 给每个服务自己的数据库账号，只给自己库的操作权限；给每个站点自己的系统用户，只给自己的目录读写权限。一条 GRANT ALL ON *.* 或者一个能读全部站点的 FTP 账号，等于把所有防线一次性打通。

查看 zorocloud 当前月价与库存

第三，每半年做一次「假设已被入侵」的桌面推演。 写下从发现异常到恢复服务的每一步：谁第一时间看告警、怎么确认被入侵、要断网取证还是直接重装、数据从哪里恢复、多久能对外服务。这个推演写出来之后，真正出事时就不用临时想。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 spinservers 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 zenlayer 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、常见问题

问题一：改 SSH 端口后自己连不上了怎么办？ 从云控制台的 VNC 或救援模式登录，把 /etc/ssh/sshd_config.bak 复制回去再重载。这就是改配置前必须备份的原因。

问题二：禁用密码登录后，scp 命令还能用吗？ 能，只要用的是密钥。scp -i ~/.ssh/id_ed25519 file user@host:/path 这样写。

问题三：fail2ban 不工作，日志里没记录？ Debian 12 和 Ubuntu 24.04 改用 systemd journal 了，要在 jail 配置里加 backend = systemd。用 journalctl -u ssh --since "10 min ago" | grep -c Failed 确认日志源有内容。

问题四：防火墙开了之后网站访问不了？ 检查规则里有没有 80 和 443。ufw status numbered 看一眼，通常是加规则时漏了。

问题五：自动更新会不会把我的服务更新坏？ 这就是为什么要用 Package-Blacklist 把 PHP 这类关键包挡掉，只让安全更新自动跑。内核更新也不会自动重启（Automatic-Reboot 默认 false），需要你手动挑时间重启。

问题六：怎么知道我的机器有没有被入侵过？ 用第六节的七类检查逐项过一遍。最关键的三项是：SSH 密钥有没有多出来的、计划任务有没有不认识的、进程里有没有 exe 已删除的。这三项能覆盖大部分入侵场景。

问题七：装了 fail2ban 还是被打挂了？ 检查 jail 的 port 是不是和你改后的 SSH 端口一致。还有一种情况是攻击者换成了别的服务（比如 Web 后台爆破），那需要给对应的服务单独配 jail。

问题八：数据库要不要暴露给其他机器？ 要，但必须同时做两件事：绑定内网 IP 而不是 127.0.0.1，以及用防火墙规则只允许内网网段访问。只做一件等于没做。

问题九：Redis 和 Memcached 要不要设密码？ 要。Redis 从 6.0 开始支持 requirepass，Memcached 从 1.5.12 开始支持 -A 参数。但设了密码不等于安全——未授权访问是绕过密码直接连上来的漏洞，所以绑定内网和防火墙限制同样必须做。

问题十：日志要保存多久？ 30 天是一个合理起点，能覆盖大部分攻击的潜伏期。磁盘紧张的话可以用 logrotate 压缩旧日志，但不要在保留期内删除。

问题十一：加固会不会影响性能？ 影响很小。禁用密码登录省的是登录时的 CPU 校验；fail2ban 用 iptables/ipset 规则匹配，规则多到几千条时才有可测量的开销。加固和性能在常规配置下不冲突。

问题十二：机器被入侵了，最省事的处理是什么？ 重装系统。这是唯一能保证干净的做法。然后逐项恢复数据，恢复时对每个文件都判断一下是否该信任。清理脚本无法保证抹掉内核层的后门。