VPS搭建后怎么防止被攻击：四步加固清单

装完VPS先动SSH，还是先装fail2ban？只能挑一件先做，先动SSH。它是远程控制的主要入口，fail2ban要等试错发生以后才动手。还有一个默认状态要先知道：Ubuntu上的ufw装好是关着的，不做任何操作，这台机器等于没有防火墙。

对出海做站的人来说，这台机器上放的是站点、数据库和备份。被爆破进去，重装一次都是小事，数据丢了才是真麻烦。机器稳定以后真正花时间的，是出事以后回查日志。买之前挑机器可以看vps主机，第一次连服务器的手顺看SSH 上手步骤。

• 四步的顺序：SSH登录口、防火墙只放行必要端口并开日志、fail2ban兜底、逐项验收
• ufw默认关闭，跑 sudo ufw status verbose 先看状态
• 改sshd配置，先检查再重启，配错可能进不去
• 防火墙日志要自己开，跑 sudo ufw logging on

这篇只讲服务器自己这一侧的加固，动作、命令、出问题往哪查，能照着做。

建站后被攻击，通常是从哪几个口子进来的

一台VPS能不能被攻进来，先看它对外露了什么。系统装完、网站跑起来，露在外面的东西比看上去多。按暴露时间长短看，有三个口子。

SSH是默认暴露在公网的那个口

OpenSSH是远程控制和传输数据的工具集，替代telnet、rcp这类明文传密码的旧工具。它的服务端sshd会持续监听客户端连接，支持明文密码、公钥加密、Kerberos票据等多种认证方式。只要密码认证开着，扫到这个端口的人就能一直猜下去。

从系统装好到网站能打开，SSH是第一个被打开的入口，VPS搭建网站教程 里那套顺序，第一步也是连上服务器。这一层不收，后面防火墙和日志做得再细，也等于留了一扇没锁的门。

防火墙默认没开，等于门没锁

Ubuntu默认的防火墙工具是ufw，作用是简化iptables配置，提供一个方便的方式建IPv4或IPv6的主机防火墙。内核里的netfilter子系统负责处理进出服务器的流量，所有现代Linux防火墙方案都靠它做包过滤。

但ufw的初始状态是关闭的。装好系统不等于有防火墙，没动过的机器，status verbose返回的是inactive。

日志默认不产生，出了事看不见

官方把防火墙日志列为识别攻击、排查规则、发现异常活动的关键。问题在于日志必须自己加规则才会产生，而且日志规则要放在终止规则之前，否则流量已经被挡下，后面不再记。

不配日志的机器被扫一整晚，/var/log/syslog里也可能一行记录都没有。真出事那天，手里没有日志，只能猜。

第一步：先把SSH登录口收紧

这一步动的是/etc/ssh/sshd_config，或者它下面的片段文件。整套动作里，这一步可能把自己关在门外，顺序一步都不能乱。

改配置前先备份，改完先跑 sudo sshd -t

官方建议在编辑配置之前，先把/etc/ssh/sshd_config复制一份并去掉写权限，留着当原始设置参考。官方同时警告：如果SSH是你访问服务器的唯一方式，配置写错，重启后可能被锁在服务器外；指令写错还可能导致sshd拒绝启动。

所以改完任何一行，先跑 sudo sshd -t 检查配置。没有输出报错，再用 sudo systemctl restart ssh.service 重启。跳过检查直接重启，运气不好就可能被锁在服务器外。

两个习惯值得养。改之前用tmux或screen起一个会话，断线后还能接回来；用etckeeper把/etc的改动记进git，改错了能看出是哪一行。这两样官方都提过。

用密钥登录替代密码

官方推荐用ed25519算法生成密钥，理由是密钥更短、计算需求更低，也支持RSA 4096位。本机跑 ssh-keygen -t ed25519，公钥默认落在 ~/.ssh/id_ed25519.pub。

把公钥装到服务器上用 ssh-copy-id username@target_machine，它会把公钥内容追加到目标机的 ~/.ssh/authorized_keys。

装完检查权限。authorized_keys只有被认证用户本人应该有写权限，不对就用 chmod go-w .ssh/authorized_keys 改。权限不对，密钥配得再对也登不上。

改端口、关掉密码登录

sshd_config顶部默认有一行 Include /etc/ssh/sshd_config.d/*.conf。OpenSSH对多数指令取第一个设定的值，所以片段目录里的设置会覆盖主配置文件。要改的东西写进片段，出问题删文件就能回滚。

改端口和关密码登录这两件事，发行版文档里没有现成模板。

关密码登录之前，一定先用密钥登进去一次。新开一个终端窗口验证，登上了再关旧的。这个顺序反了，旧窗口一关就没入口了。

顺手把banner里的系统信息关掉

SSH连上来会先吐一行banner。官方示例里带着系统版本，形如 OpenSSH_10.2p1 Ubuntu-2ubuntu1，等于主动告诉扫端口的人这台机器跑的是什么。

在sshd_config或片段里加一行 DebianBanner no，重启后用 nc -nv 127.0.0.1 22 连本机看，banner会变成只有 SSH-2.0-OpenSSH_10.2p1 这一段。

出问题怎么回查

密钥登不上，先看目标机的实时日志 sudo journalctl -fu ssh.service。日志会直接说认证失败在哪一步，比反复试密码快得多。

改完配置先别关旧窗口，就是这个道理。旧窗口是退路，新窗口是验收。

第二步：防火墙只放行网站真正要用的端口

SSH收紧以后，把机器上多余的口都关掉。网站对外只需要80和443，SSH用哪个端口就放哪个，其余不放行。

先看清现状

sudo ufw status verbose 先看一眼。没动过的机器是inactive。已经active的，先看清楚现在放了哪些端口，别在已有规则上乱加。

放行顺序：先SSH新端口，再网站端口，最后enable

顺序是：先 sudo ufw allow 放行你正在用的SSH端口，再放网站要用的那两个，最后 sudo ufw enable。先enable再放SSH，命令发出去那一瞬间连接就断了，只能进救援模式。

端口在/etc/services里有定义的话，可以用名字代替数字，22写成ssh。改过SSH端口的，这里就写新端口号。

拿不准就先dry-run，规则顺序用numbered调

ufw命令加 --dry-run，只输出结果规则、不实际应用。不确定一条命令会写成什么样，先跑一遍看输出，确认了再执行。

sudo ufw status numbered 能看到每条规则的编号，sudo ufw insert 1 allow 80 可以插到第一条。删规则用 sudo ufw delete deny 22。

管理口只允许特定来源

如果SSH只有固定的几个IP会用，可以只放行这些来源：sudo ufw allow proto tcp from 192.168.0.2 to any port 22。把192.168.0.2换成192.168.0.0/24，就是放行整个子网。

代价是换个网络就进不去，出门在外得先回后台加IP。要不要收这么紧，看你自己常在哪些地方办公。

开日志

sudo ufw logging on 把日志打开。ufw的日志会同时出现在/var/log/messages、/var/log/syslog和/var/log/kern.log。

这一步不做，后面所有排查都是盲的。

出问题怎么回查

规则不生效，先看/etc/ufw/*.rules。每个表都要有对应的COMMIT语句，删掉或者写漏，那一部分规则根本不处理。

装了面板的机器，端口可能被面板改过。sudo ufw app list 看有哪些应用profile，sudo ufw app info 看某个应用要哪些端口，按应用放行用 sudo ufw allow 应用名。面板自己的端口要在ufw里单独放行一次。

第三步：装fail2ban，把反复试密码的IP挡在外面

前两步做完，机器已经不容易被猜进来。fail2ban是第三层，它不改配置，只负责在有人反复试错的时候把来源IP封掉。

它具体干什么

fail2ban读日志，按过滤器里的正则匹配失败记录，命中就按配置封掉来源IP。过滤器文件放在config/filter.d/{filtername}.conf，分INCLUDES和Definition两节，failregex和ignoreregex都写在Definition里。

自己新增过滤器，官方要求先在config/jail.conf里加条目，并保证 enabled = false，让用户按需启用，不要默认打开。

安装与启用

安装这件事，官方开发者文档里没有给命令。

官方示例里给sshd的条目用的是maxretry=5。这个数是示例，不是通用推荐值。

自己写过滤器，最容易踩的坑在主机名锚定

官方专门提醒，过滤器正则写得松，会被拿来做拒绝服务。远程用户只要能插入一段既匹配failregex、又能对上<HOST>部分的文本，就能借你的过滤器封掉任意主机。

要求很明确：<HOST>必须锚定在应用生成的文本上，不能落在用户能插入的地方。新写一条规则，先用 fail2ban-regex 拿日志样本测。

出问题怎么回查

封禁不生效，先确认jail读的日志路径和实际写日志的文件是同一个。路径对不上，过滤器写得再好也匹配不到东西。

四步做完，先做哪个、做到什么程度算够

顺序不是随便排的。SSH是远程控制入口，做错的代价最大，排第一。防火墙一条命令能砍掉一大半端口，收益最快，排第二。日志是后面所有排查的前提，排第三。fail2ban是兜底，排第四。

倒过来做也能做完，但中间任何一步出问题，你都会缺一份能对着看的记录。

每步的验收标准

1. 改过的sshd配置检查通过，没有任何输出报错。
2. sudo ufw status verbose 状态是active，列表里只有你打算放行的端口。
3. /var/log/syslog 里能看到UFW开头的挡下记录。
4. fail2ban-client status 里能看到sshd这个jail，状态是启用。

四条都能对上，这一轮加固就算做完。对不上哪条，回哪一节查。

什么情况下这四步不够

这四步管的是登录口和端口。如果攻击落在带宽和连接数上，比如大量IP同时打网站端口，把带宽占满，本机规则挡不住，因为这些请求看起来是正常的HTTP请求。

这种情况要看机器本身有没有防护能力。自带高防 的机型在机房那一层先把流量洗一遍，省掉自己在系统里加规则。选机器时把这一项和线路、备份一起看，国外vps租用怎么选 里那几个判断能用上。

做到哪一步算够，取决于这台机器上放的东西值多少。一个测试站做到第二步就够；跑着收款和客户数据的站，四步都要做完，日志还要定期看。

数字和限制：这套加固里几个要记住的数

这套动作里的数字不多，但都是从官方文档里抄下来的，记错会做错。

真正影响操作的只有前两行，后两行是选系统版本时的判断。生产环境用LTS，别用过渡版本，理由就是更新期差着一大截。

ufw官方手册页还有一句要记住：它不打算通过命令接口提供完整防火墙功能，只提供添加或删除简单规则的简便方式，目前主要用于主机防火墙。要按zone管、要动态改规则，得上firewalld；要写复杂规则，直接写iptables。

用firewalld的机器要注意目录。默认配置在/usr/lib/firewalld，包提供的文件不该改，改了随包更新就丢。要改就复制到/etc/firewalld的对应位置再动。

常见误区：这几件事做了等于没做

下面这几条，都是配置看起来做了、实际没起作用的情况。

• 以为放行网站端口就算加固完了，SSH的密码认证还开着。端口开得再少，登录口一直能猜密码，等于没关。
• 改完sshd配置不检查就重启。官方写明配错时sshd可能直接拒绝启动，重启那一刻就是断线那一刻。
• 以为防火墙日志自动就有。官方写明必须自己加日志规则才会产生，而且日志规则要放在终止规则之前。
• 直接改/usr/lib/firewalld下面的默认配置。包提供的文件不应改动，改动会随包更新丢失。
• 手动编辑时删掉/etc/ufw/*.rules里的COMMIT行。每个表都要有对应的COMMIT语句，少了它规则不被处理。
• 密钥登不上就先怀疑密钥。先看 sudo journalctl -fu ssh.service 的实时日志，再查authorized_keys的权限是不是只有本人可写。

这六条里，前三条查起来最快：状态命令一跑，日志文件一看，就知道有没有生效。

一次日志排查：从网站变慢到定位到扫描

网站突然变慢，先别急着重启服务。按下面的顺序看一遍，十分钟内能分清是攻击还是配置问题。

1. sudo ufw status verbose 看防火墙状态和放行列表，再看/var/log/syslog里有没有大量挡下记录。有，说明流量已经在被挡。
2. 按来源IP、端口、时间把日志行归类。日志量大就用logwatch、fwanalog、fwlogwatch这类分析工具，比人眼翻快。
3. 判断方向。同一个IP高频打同一个端口，是扫描或爆破，交给fail2ban。多个IP同时打网站端口，流量还很大，可能是CC，本机规则挡不住。
4. 动手。SSH爆破确认以后，把fail2ban的封禁时长和重试次数调紧；流量型的，要么换一台带防护的机器，要么先把IP换掉止血。

归类这一步做不做，区别很大。日志不归类，看到的只是一屏文字；按来源、端口、时间三列一摆，是扫描还是正常访问，一眼能分开。

如果查下来服务器本身跑得慢、跟攻击无关，那要看的是另一套东西，VPS速度慢如何加速 里的顺序可以对着查。IP已经被打黑或者进了别人的封禁列表，换IP的流程在VPS换IP怎么换。

用AI帮你把这套加固整理成可执行清单

这套动作真正花时间的，是敲命令之前把官方几页文档对照清楚，别抄错参数。这部分可以交给AI先整理，人只负责跑和验。

能帮上的有几步。把Ubuntu官方ufw文档里的命令示例整理成开端口、关端口、看状态、开日志四类对照清单，照着敲。把sshd_config要改的指令列成改动前后对照表，标出哪几行必须改。把fail2ban过滤器文档里的要点整理成检查清单，重点标出正则里最容易被利用的那一处。日志出来以后，把syslog和journalctl里的关键行摘出来，按来源IP、端口、时间归类。

三条提示词可以直接抄，都是本文给的示例，不是官方模板。

1. 按Ubuntu官方ufw文档，给我一份命令清单：启用、开22端口、开80和443、看状态、开日志，每条命令后面用一句话说明作用，不要加文档里没有的命令。
2. 我要改/etc/ssh/sshd_config里的DebianBanner和SSH端口，按Ubuntu官方OpenSSH文档给我一份改动前后对照表，标明改完先跑哪条检查命令、再跑哪条重启命令。
3. 按fail2ban官方过滤器文档，列出写failregex时要注意的5条规则，每条用一句中文说清，重点说明匹配主机名的部分为什么要锚定在应用生成的文本上。

AI出的是清单，跑还得人来跑。有三件事必须自己动手：在服务器上跑 sudo sshd -t，看有没有报错，有报错就不重启；跑 sudo ufw status verbose，确认要放行的端口都在列表里、状态是active，再决定要不要接着改别的规则；改完sshd以后另开一个终端窗口用新配置登一次，登上了再关旧窗口，登不上就回滚备份。网站跑起来以后，掉流量要排查原因，这步可以交给猎者出海的AI Agent 拉数据排查。

常见问题

ufw能当完整防火墙用吗？

不能。官方手册页说它不打算通过命令接口提供完整防火墙功能，只提供添加或删除简单规则的简便方式，目前主要用于主机防火墙。要按zone管、要动态规则就上firewalld，要写复杂规则直接写iptables。

改sshd配置前要注意什么？

先备份原文件并去掉写权限，改完先检查配置再重启。SSH是唯一访问方式时，配错可能导致重启后进不去，sshd本身也可能拒绝启动。

怎么让ufw命令先看结果不生效？

命令后面加 --dry-run，只输出结果规则、不实际应用。拿不准一条命令会写成什么样，先跑一遍看输出，确认了去掉这个参数再执行。

怎么让SSH banner不暴露系统信息？

在sshd_config或sshd_config.d的片段里加 DebianBanner no，重启sshd。再用 nc -nv 127.0.0.1 22 连本机看，banner里就不带系统版本那一段了。

怎么给SSH加双因素认证？

有硬件的话用U2F/FIDO认证设备，在密钥登录之上再加一层。手上没有硬件，可以用HOTP/TOTP这类一次性密码方案。

机器加固做完一次，留下的是一条能查的线索。哪天站点真的被打，日志里那几行挡下记录比任何猜测都管用。站跑起来以后，掉流量排查可以交给猎者出海的AI Agent 拉数据，服务器这四步还是得自己盯着。