VPS如何防止扫描端口：可行做法与顺序

一、扫描端口这件事本身不是漏洞，别被吓到

全网扫描每时每刻都在发生。互联网上的自动化工具用几十万个 IP 轮询常见端口，寻找开放的服务、弱口令后台、可利用的组件版本。绝大多数机器每天都会被扫几十到几百次，这不等于有人在针对你。要区分两件事：被动扫描是全网无差别的机会主义行为，扫到你就试一下，扫不到就走；定向攻击是有人专门盯上了你的 IP，会持续探测、尝试爆破、投递利用。判断自己是不是被定向了，看的是行为有没有持续性和针对性，而不是看扫描日志里有多少条记录。

真正有意义的问题是：扫描器在你的机器上发现了什么可利用的东西。一个只开放 22 端口且密钥登录、无弱口令、已打补丁的机器，对扫描器来说几乎没有价值；一个开放了 22、3306、6379、面板端口并且数据库密码简单的机器，扫描器扫到的每一条都能直接变成入侵路径。

# 看看自己机器上现在开着什么端口（ss 比 netstat 更准）
ss -tulnp | sort -k5
# 只看监听态，区分 127.0.0.1 和 0.0.0.0/:: 的差别
ss -tulnp state listening

# 找出哪些服务在对外提供，检查绑定地址
sudo lsof -i -P -n | grep LISTEN

判定标准要明确：只监听 127.0.0.1 的服务等于不存在，扫描器从外网根本扫不到。真正需要收敛的是绑在 0.0.0.0 或通配地址上的那些监听。理解这一点，你的收敛工作量和实际风险差距可能比想象中大很多。

还要分清两种扫描。水平扫描是扫同一网段内的不同 IP，寻找同款系统的其他机器；垂直扫描是对同一个 IP 扫不同端口，寻找这台机器上的不同服务。你在日志里看到的绝大部分是水平扫描的噪声，真正针对单台机器的威胁来自垂直扫描和定向利用。

另一个判断维度是扫描的时间分布。无差别的机会主义扫描会均匀分布在全天；定向攻击往往在你业务活跃的时段出现，因为它要蹭你的流量高峰来投毒或压测。如果你的日志显示某个 IP 在你的业务高峰期反复出现，那比一百条随机扫描更值得警惕。

# 统计 SSH 失败登录的来源 IP 排行，前十名最值得看
sudo awk '/Failed password/{print $1}' /var/log/auth.log | sort | uniq -c | sort -rn | head -10

# 找出按小时分布的扫描量，判断是否集中在业务时段
sudo awk '/Failed password/{print substr($1" "$2" "$3,1,13)}' /var/log/auth.log | uniq -c | tail -24

这两个命令跑完，你对自己被扫的程度就有了具体认知，而不是凭感觉判断。

查看 iwebfusion 当前月价与库存

二、真正需要保留的开放端口只有少数几个

一台普通网站服务器的最小暴露面通常只有两个：SSH 的 22 端口和 HTTP/HTTPS 的 80 和 443。其余所有端口都应该是关闭的，或者只监听在回环地址上。这个结论看起来激进，但它是行业实践了几十年的共识——每一个多开的端口都是一条潜在的攻击路径。

现在把常见端口分成三类，逐类处理。

必须留的：22（SSH）、80（HTTP，做跳转和证书验证）、443（HTTPS，主业务）。如果你用了面板，还要留面板端口，但它最好只对你自己的固定 IP 开放。

绝对不该对外的：数据库端口 3306（MySQL）、5432（PostgreSQL）、1433（MSSQL）、6379（Redis）、27017（MongoDB）、9200（Elasticsearch）、11211（Memcached）。这些服务的设计前提是「可信内网内访问」，裸露到公网等于把数据直接送出去。只要应用和数据库在同一台机器上，它们就应该绑 127.0.0.1。

按需处理的：邮件的 25、465、587（多数情况下根本不需要发信）、21（FTP，早该被 SFTP 取代）、代理的 1080、3128、某些面板的随机端口、监控 agent 的端口。

# MySQL 改绑回环：找到配置文件里的 bind-address
grep -rn "bind-address" /etc/mysql/ /etc/my.cnf 2>/dev/null
# Redis 默认没设 bind 时监听所有，改成回环
grep -n "^bind" /etc/redis/redis.conf

数据库这类服务改绑地址是收益最高、见效最快的一步，五分钟就能把最大的一个漏洞面封掉。

还有一类容易漏的是容器端口映射。用 Docker 跑服务时，如果用了 -p 0.0.0.0:6379:6379 这种写法，等于把容器端口直接暴露到公网，哪怕应用本身配置正确。Docker 默认会把容器端口映射到宿主机的所有地址上，除非你明确指定绑定地址。检查所有容器的端口映射是最容易出问题的环节之一。

# 列出所有容器的端口映射，重点看左边那一列是不是 0.0.0.0
docker ps --format "table {{.Names}}\t{{.Ports}}"

# 改成只绑回环，外部就访问不到了
docker run -d -p 127.0.0.1:6379:6379 你的镜像

# 确认实际监听状态
ss -tulnp | grep docker-proxy

同样的坑还有 systemd 服务通过 ListenStream=0.0.0.0:端口 声明的监听，以及某些面板自动装的监控 agent。排查的时候要覆盖这三类，而不只是 /etc/services 里那几百个标准端口。

# 找出所有 systemd 服务里声明的非标准监听端口
grep -rhn "ListenStream" /etc/systemd/system/ /lib/systemd/system/ 2>/dev/null | grep -v "127.0.0.1\|::1" | head -20

查 racknerd 在售套餐与库存

这一节的逻辑是：端口不是一个个「有名字的常见端口」，而是「每一个正在监听的套接字」。用工具把所有监听点全捞出来，再逐个判断，比凭记忆列出常见端口要可靠得多。

三、防火墙规则怎么写才不会把自己锁在外面

这是操作环节里最容易出事的一步：规则写错，SSH 连不上，人就再也进不去服务器了。防锁的原则是永远先放行，再收紧，并且保证当前 SSH 会话不中断。

正确顺序是这样的：第一步，把当前 SSH 会话记录下来，确认它的来源 IP；第二步，加一条放行当前来源 IP 的 SSH 规则，并且这条规则放在拒绝规则之前；第三步，设置规则在若干秒后自动生效延迟，或者用一条命令在规则生效前自动删除自己；第四步，另开一个新终端测试能不能连上，连不上就用原来的会话改回来；第五步，确认新会话能连上后，再删掉那条临时放行规则。

# 查看当前 SSH 连接来源 IP（这一步的输出要记下来）
who | awk '{print $NF}'
ss -tn state established '( sport = :22 )'

# ufw 的安全写法：先放行，再默认拒绝，最后启用
ufw allow from 你的固定IP to any port 22 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

# 改完立刻用新终端验证，不要关掉当前会话

如果你用的是 firewalld 或者云厂商的安全组，逻辑是一样的：安全组在网络层，通常是最外层的一道，优先级最高，先在那里定好规则，再在系统内配防火墙。两道都要配，但先配外层——外层配错了系统内的规则救不了你。

有一个细节值得强调：不要依赖「只允许特定 IP 访问 SSH」这一条策略。它在你换网络、换 IP、紧急救援时会把你挡在外面。正确的做法是 SSH 本身用密钥登录并禁用密码，这样即使 IP 规则配错，暴力破解这条路也是封死的。

# SSH 加固三件套：禁密码、禁 root 直登、限制尝试次数
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
cat >> /etc/ssh/sshd_config <<'EOF'
MaxAuthTries 3
LoginGraceTime 30
EOF
sshd -t && systemctl reload sshd

再补两条经常被忽略的 SSH 加固配置。第一条是改端口，作用不是让扫描器找不到（扫全端口段的工具几秒就能找到），而是让那些只扫 22 端口的廉价扫描器直接跳过你，日志会干净很多。第二条是限制可登录的用户，用 AllowUsers 白名单，只允许指定账号登录，其余全部拒绝。

# 改端口（改完保留原会话，新开终端验证）
sed -i 's/^#*Port 22/Port 你的新端口/' /etc/ssh/sshd_config
# 只允许指定用户登录
echo "AllowUsers 你的用户名" >> /etc/ssh/sshd_config
sshd -t && systemctl reload sshd

AllowUsers 这一条比改端口更有实际价值，因为它把爆破面从「所有合法用户名」缩小到「一个」，配合禁用密码登录，SSH 这条入口基本就封死了。

一个必须提前确认的点：密钥文件本身要安全。私钥放在本机，权限设成 600，用密码管理器管理 passphrase，不要放在网盘同步目录里。同时确保你有第二把密钥或者有云厂商的救援模式，否则私钥丢了就只能走人工工单。

# 生成密钥对（一路回车用默认路径）
ssh-keygen -t ed25519 -C "你的标识"
chmod 600 ~/.ssh/id_ed25519
# 把公钥推到服务器
ssh-copy-id -i ~/.ssh/id_ed25519.pub 用户名@服务器IP

查 cloudcone 在售套餐与库存

把这段做完，你已经不再依赖「只允许特定 IP」这种脆弱策略了。即便你的固定 IP 变了、换了网络、用了别的出口，只要带着私钥就能登进。

四、按这个顺序做，可以避开所有常见踩坑

端口收敛这件事有明确的先后顺序，做对了能省掉大量返工。完整的顺序是这样。

第 0 步：备份与留后路。先给服务器拍一个快照，或者至少把当前防火墙规则导出存好。很多云厂商控制台都有「救援模式」「VNC 登录」这类不经过 SSH 的入口，这是你把自己锁在外面时唯一的救命通道。开始之前确认自己能进入这个通道。

第 1 步：确认业务真正需要哪些端口。列出对外提供服务的所有应用和它们的端口，别凭印象。这一步要问清楚：面板在哪、数据库在哪、应用在哪、有没有对外的 API、有没有定时任务需要拉取外部服务。

第 2 步：把内部服务改绑回环。数据库、缓存、消息队列、内部微服务，全部改成只监听 127.0.0.1。这一步不需要防火墙规则就能让这些端口从公网消失。

第 3 步：停掉不用的服务。不是靠防火墙挡住，而是真正停掉进程。systemctl disable --now 掉不用的服务既减少暴露面，也省内存。靠防火墙挡住一个还在监听的服务，它依然占用端口、依然消耗资源。

# 列出所有正在运行的服务，按状态筛选
systemctl list-units --type=service --state=running
# 停掉并禁用不用的
systemctl disable --now 服务名

# 找出开机自启但从没被用到的服务（systemd-analyze 很实用）
systemd-analyze blame | head -15

第 4 步：配置防火墙。按第三节的顺序做，先放行后收紧。

第 5 步：验证。从外部机器扫描自己的 IP，确认只有预期的端口开放。这是唯一能证明前面四步真的生效的方法。

第 6 步：设监控。用定期扫描自己的服务，异常开放端口第一时间告警。

这个顺序的核心是：先减少服务，再限制端口。反过来做（先用防火墙全封，再一个个放行）容易在第 4 步把自己锁住，而且你会分不清是防火墙规则写错还是服务配置有问题。

还有一点：收敛要一次做完，不要分多次改。每次改完都要重新验证连接，分五次改就意味着五次把自己锁住的风险。找出一个完整的时间窗口（通常是半夜或者能随时进控制台的时候），把上面六步连着做完，比零散地改安全得多。

第 5 步的验证容易被跳过，但它是唯一能证明前面所有步骤真的生效的手段。很多人改完规则，看到本地 ss 输出正常就认为完成了——但外部扫描器看到的可能完全不一样，因为云安全组、宿主机的额外规则、你自己的其他工具都可能改变结果。外部验证不可省。

# 完整验证清单：一条条跑，全部符合预期才算完成
ss -tulnp state listening | grep -v "127.0.0.1\|::1"   # 期望只有必要端口
systemctl list-units --type=service --state=running | wc -l  # 记录服务数，做前后对比
curl -s -o /dev/null -w "站点=%{http_code}\n" https://你的域名
mysql -h 127.0.0.1 -u root -p -e "show databases;" 2>&1 | head -5

digitalocean 官网机型与实时报价

把这几条的输出存下来，下次再做收敛时可以直接对比差异，能省掉大量重复排查。

五、外部自查：怎么从外面看自己的暴露面

内部视角看到的端口列表和外部视角不完全一样，因为 NAT、防火墙、云安全组都可能改变实际暴露情况。必须从外部验证。

最直接的办法是在另一台机器上扫描自己的 VPS 端口。

# 用 nmap 从外部扫自己的 IP，只看开放端口
nmap -Pn -sT -p- --min-rate 2000 你的VPS公网IP
# 简化版：扫常用端口，快速看结果
nmap -Pn 你的VPS公网IP

# 用 nc 逐个端口验证
nc -zv -w 2 你的VPS公网IP 3306
nc -zv -w 2 你的VPS公网IP 22

# 从你自己的网站服务器上反查（不影响本机）
curl -s https://api.ipify.org

验收标准写成数字最清楚：从外部扫描，开放的端口数量应等于业务必需端口数量加一两个管理端口。如果你只跑一个网站，期望值就是 22、80、443 这三个。实测发现 3306 或 6379 开着，立刻处理。

除了端口本身，还要看端口上的服务版本。扫描器认的不是端口号，是服务指纹。SSH 横幅里会写版本号，HTTP 响应头里会有服务器版本，很多老旧组件的默认页面还会直接告诉你用了什么。

# 看 SSH 横幅
nc -v 你的VPS公网IP 22
# 看 HTTP 响应头
curl -sI https://你的域名 | grep -Ei "server|x-powered-by|x-version"
# 看哪些端口对应什么服务（nmap 带版本探测）
nmap -sV -p 22,80,443,3306,6379 你的VPS公网IP

版本信息本身不是漏洞，但它是扫描器匹配利用代码的索引。把版本号从响应里去掉，能让扫描器的自动化利用流程失效一大半。

改版本号隐藏的方法因组件而异。nginx 用 server_tokens off; 就能去掉版本号。PHP 的 expose_php = Off 可以去掉 X-Powered-By 头。Apache 的版本号在 Server 头里，改 ServerTokens Prod 就只显示 Apache 而不显示版本。做完这些，curl -sI 的输出里就不再有具体数字，扫描器的指纹匹配会直接落空。

# nginx: 隐藏版本号
# 在 server 块里加：
# server_tokens off;

# Apache: 只显示产品名不显示版本
sed -i 's/^ServerTokens .*/ServerTokens Prod/' /etc/apache2/conf.d/security.conf
a2enmod headers && a2enconf security

# PHP: 关闭 expose_php
sed -i 's/^expose_php = .*/expose_php = Off/' /etc/php/*/fpm/php.ini
systemctl restart php*-fpm

# 验证
curl -sI https://你的域名 | grep -Ei "server|x-powered-by"

要清楚一点：隐藏版本号是减少信息泄露，不是修复漏洞。它挡的是自动化的通用扫描，挡不住有人拿到具体版本号后去查对应公告。所以补丁更新仍然是第一位，隐藏版本号排在它后面。

查 hostwinds 在售套餐与库存

对外暴露的还有一类东西容易被忽略——管理后台路径。宝塔默认路径是随机字符串，WordPress 的 /wp-admin/、面板的 /login 都是公开可知的。给后台加一层路径改写、或者加 HTTP 基本认证、或者干脆限制来源 IP，能把自动化的后台爆破挡在门外。

六、哪些端口关了反而会出问题

收敛端口不是越多越好，有些端口关掉会直接让业务停摆，这一节是最容易翻车的地方。

25/465/587 邮件端口。如果你用服务器上的应用直接发信（比如注册验证邮件、订单通知），这三个端口关掉之后应用会报连接超时。这类场景要么改用第三方邮件服务的 API，要么在本地装一个只监听回环的 MTA 前置。不要因为「用不着邮件端口」就一刀切。

面板端口。宝塔、aaPanel、1Panel 这类面板通过一个特定端口提供 Web 管理界面，关掉之后你就没有图形化入口了。正确做法不是关掉，而是限制来源 IP。

80 端口。很多人在 443 上配好 HTTPS 就把 80 关了，结果证书自动续期失败——签发机构验证域名所有权需要通过 80 端口访问 /.well-known/acme-challenge/ 路径。保留 80 并配好跳转规则，是最省事的做法。

你不知道自己在用的端口。有些应用会在启动时随机选一个空闲端口，比如某些数据库的集群模式、或者用 ZeroTier、Tailscale 这类组网工具时。这类端口在 ss 里能看到，但要确认它是不是需要对外可达。

# 找出所有对外监听（0.0.0.0 / :: / 具体公网 IP）的端口
ss -tulnp | grep -v "127.0.0.1" | grep -v "::1"

# 找出哪些服务是从 systemd 起的，方便追溯
ss -tulnp | grep -oP 'pid=\K[0-9]+' | sort -u | while read p; do
  systemctl status $(cat /proc/$p/cgroup 2>/dev/null | grep -oP '[^/]+\.service' | head -1) --no-pager 2>/dev/null | head -3
done

查看 interserver 当前月价与库存

判断端口是否必须对外，有一个简单的反向测试：这个服务有没有被「非本机的另一个东西」访问？本机的应用访问数据库，永远走 127.0.0.1，不需要对外。远程管理你的服务器，用的是 SSH 而不是数据库端口。真正需要对外的，只有用户直接访问的那几个。

七、除了关端口，还能做这三件事

端口收敛是第一道防线，但不是唯一一道。扫描器除了扫端口，还会做两件事：版本识别和爆破弱口令。关端口挡住了第一件，剩下那件要靠认证强度。

第一，改密码策略。所有服务密码用密码管理器生成，长度十六位以上，不在任何地方复用。这一条挡住的是纯爆破类攻击，成本最低。

第二，关掉密码登录，用密钥。这一条把爆破面直接归零。生成密钥对、把公钥写进 authorized_keys、禁用密码认证，是最标准的做法。

第三，fail2ban 之类的自动封禁工具。它监控认证日志，把短时间内失败次数超阈值的 IP 自动拉黑。配置之后，即使有人扫到了你的 22 端口并开始试密码，试几次就被封掉。这不改变你的端口暴露面，但能显著降低单 IP 的攻击成功率。

# fail2ban 基本配置：10 分钟内失败 5 次就封 1 小时
sudo apt install -y fail2ban
cat > /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
bantime.increment = true
bantime.factor = 2
ignoreip = 127.0.0.1/8 ::1 你的固定IP
[sshd]
enabled = true
EOF
systemctl restart fail2ban
fail2ban-client status sshd

查看 itldc 当前月价与库存

还有一个容易被忽略的事实：扫描日志本身是有用情报。如果你在某台机器上看到大量来自同一网段的扫描，bantime 递增机制会让封禁越封越久；如果你的服务日志里出现了来自陌生 IP 的成功登录，那才需要立刻处理。

八、选机器时就把暴露面考虑进去

端口防护的起点其实在选机器那一步。有些套餐的默认配置就带着额外的暴露面，选之前看清楚能省掉后面一半的工作。

需要关注的是这几项：是否默认开放面板端口、面板是否支持限制来源 IP、是否提供快照或救援模式（这是你锁在外面时的后路）、是否支持附加 IP（附加 IP 是搭建备用通道的好材料）、是否提供 DDoS 防护（防的是流量型攻击，和端口收敛是两件事）。

具体到广告库里能查到结构化套餐的商家：云途的香港与欧洲节点系列在流量额度超出后有明确的续费价格档位，最低一档 200 美元，更高档位按机型不同上浮，说明这类商家把「超额限速」做成了规则化条款而不是临时行为——这种条款化的行为在长期使用里是可预期的，比不明说但随时可能变要好。justg 的 RosCloud 系列是月付制，从 19.99 美元起步逐档递增，每档都带 1 个 IPv4，月付意味着你可以随时换机器重新验证自己的配置，不必担心年付锁定。sixtynet 的洛杉矶系列则是年付制，价格从 200 美元到 1600 美元不等，端口给到 2000 到 10000 Mbps，流量从 5000 到 40000 GB。具体报价与库存以官网当日报价为准。

查 spinservers 在售套餐与库存

对个人用户来说，最省心的组合是：选月付、确认有快照或救援模式、选不需要面板的方案（直接用命令行和 SSH 管理）、优先选择流量额度明确可预期的商家。这四条能把端口暴露面的工作压到半小时以内完成。

九、什么情况下不该自己关端口

有几种情况，关端口的收益是负的，必须交给别人处理。

第一种：需要承接 DDoS 流量型攻击。这类攻击的解法是流量清洗和线路防护，不是关端口。spartanhost、tudcloud 这类商家在产品说明里把 DDoS 防护 VPS 作为主要产品线，说明防护是它们的核心能力。这类场景下你应该找带防护的方案，而不是自己在服务器上想办法。

第二种：需要做端口转发或隧道。如果你要用 SSH 隧道暴露内网服务、或者做 WireGuard 组网，那么主动维护端口映射规则是你的正常工作的一部分，不是漏洞。这时候应该做的是把映射范围收紧到最小必要集合，并给组网接口设置访问控制。

第三种：托管的是对外业务系统。如果你的服务需要被外部系统主动连接——比如提供一个 API 给第三方调用、一个 Webhook 接收端、一个需要被外部节点连入的节点服务——那么这些端口就是业务本身，关掉等于关停业务。这时该做的是认证、限流、来源白名单，而不是封端口。

第四种：你无法验证收敛后的业务是否正常。有些服务依赖特定的端口做内部通信，关掉一个看着没用的端口可能让某个定时任务静默失败。如果你没有能力做完整的功能验证，那么收敛的风险大于收益，先做第三节里那些零风险的项——改绑回环、关掉明确不用的服务、加固 SSH 认证，这三样都不需要端口层面的取舍。

zenlayer 官网机型与实时报价

# 收敛后做一次功能自检：核心页面、数据库连通、定时任务
curl -s -o /dev/null -w "首页=%{http_code}\n" https://你的域名
systemctl list-timers --all | grep -v "NEXT" | head -10
mysql -h 127.0.0.1 -u 用户名 -p -e "select 1;" 2>&1 | head -3

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

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

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 racknerd 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 cloudcone 当前机型与价格

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

十、常见问题

VPS如何防止扫描端口，第一步具体做什么？ 先从外部扫一次自己的 IP，拿到真实的开放端口清单，再对照业务需求逐条判断。内部 ss 输出只是起点，外部扫描结果才是暴露面的真实大小。

把防火墙默认拒绝设好，会不会把自己锁在外面？ 有可能，但可以完全避免。先记录当前 SSH 来源 IP 并放行它，改完立刻另开一个终端测试连接，确认新会话能登上再关闭旧会话。云厂商的 VNC 或救援模式是你的最后保险。

需要关掉的常见数据库端口有哪些？ 3306、5432、1433、6379、27017、9200、11211 都是。绝大多数场景下这些服务只该监听 127.0.0.1，改配置文件里的 bind-address 比加防火墙规则更彻底。

80 端口能不能关掉，只留 443？ 一般不建议。HTTPS 证书的自动续期通常需要通过 80 端口验证域名所有权，关掉会导致续期失败。保留 80 并把所有请求跳转到 443 是标准做法。

服务器日志里每天几百条扫描记录，要处理吗？ 被动扫描不需要逐条处理。确认你的服务版本是最新、密码足够强、SSH 已禁用密码登录之后，扫描记录就是背景噪音。真正需要警惕的是出现成功登录记录，或者来自特定 IP 的定向持续探测。

面板端口到底能不能关？ 能用命令行完成所有管理操作就可以关，需要图形界面就限制来源 IP 而不是完全关闭。折中做法是把面板放在回环地址上，用 SSH 本地端口转发访问，这样它对外完全不可见。

怎么知道我的版本有没有被扫描器识别出漏洞？ 从外部用 nmap 的版本探测扫一遍，看它返回的服务版本，对照官方公告检查是否需要升级。同时把 HTTP 响应头里的 Server 和 X-Powered-By 版本信息去掉，缩小被索引的范围。

端口收敛之后还安全吗？ 收敛解决的是「减少可被扫描到的入口」，不解决全部风险。还需要配合强密码、密钥登录、fail2ban 自动封禁、系统及时更新补丁、以及定期外部自查。收敛是把面缩到最小，不是把风险归零。

换机器会让之前做的端口配置失效吗？ 会的，系统内的防火墙规则、SSH 配置、改绑设置都在那台机器上。新机器到手要重新走一遍第四节的全流程，这也是选支持快照的商家、或者干脆用配置管理工具固化这套流程的实际价值所在。